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Le This standard establishes uniform requirements for 
software development that are applicable to all Bureau 
Computer Software Development throughout the software’s life 
cycle. The requirements of this standard provide the 
insight into software development, testing, and evaluation 
efforts. 


as This standard is a set of requirements that identifies 
what must be delivered at specific phases of the development 
effort and is not intended to specify or discourage the use 
of any particular software development methodology. It is 
the Project Manager’s responsibility to select a specific 
methodology and describe that methodology in the Software 
Development Plan. 


Bs Data Item Descriptions (DIDs) applicable to this 
Standard are provided in Bureau of Land Management document 
77-DID-000106. The format of these DIDs, shall not be 
substituted without the approval of the specific Project 
Management Board governing each specific development effort. 
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SOFTWARE DEVELOPMENT STANDARDS 


Introduction. This document identifies and describes 
requirements that shall be complied with throughout all the 
steps of software development, to include: 


e Software Development Management 
e Software Engineering 

e Quality Assurance 

e Configuration Management 


The term "software developer" refers to the individual with 
responsibility for the successful completion of a Bpecitic 
software development project. 


Purpose. The purpose of this document is to establish the 
standard requirements governing software development, to 
increase the quality of software developed for the Bureau. 


2.1 Types of Projects. Software projects vary in scope and 
diversity from simple to complex. The following are 
examples of software projects within the Bureau of Land 
Management that shall apply Life Cycle Management 
(LCM) . 


ar New Project Development. New project development 
involves the creation of complete software to 
support a new organization or a new or changed 
mission, or to replace existing software or manual 
operation which is no longer supportable or no 
longer meets the mission. 


by Existing Project Maintenance. Existing project 
Maintenance involves the restoration of software 
to an operational status, or the correction of 
problems to permit approved software to run or to 
meet its design specifications. This type of 
software project is not due to changes in 
functional or user requirements, or design 
specifications. 


Ge Existing Project Modifications. Existing project 
modifications involve incremental changes to the 


design specifications or software to ensure that 
changing functional or user requirements are met. 


Document Overview. 


Applicability. The policies and procedures contained in 
this standard apply to all software development to include 
both new development and existing projects. The scope of 
this Standard includes all Bureau software, which are 
defined as: 


a. Software primarily supporting the Bureau 


Administrative, Financial, and Resource functional 
areas. 
Da oftware primarily supporting research, development, 


test, and evaluation functions for software supporting 
the functional areas. 


ele All software within the Bureau of Land Management and 
all persons associated with the software, unless a 
waiver is granted on a case-by-case basis by the 
appropriate oversight board. 


Supporting Standards. The following supporting 
documentation shall provide the guidance to comply with the 
requirements of this standard and to assist in meeting Life 
Cycle Management goals. All software developed by the 
Bureau or for the Bureau shall remain in strict compliance 
with these Standards. Deviation from the Standards shall 
require an authorized waiver. 

a. Software Quality Assurance Program 

b. Configuration Management Plan 

c. Test and Evaluation Master Plan 

dad. Quality Assurance Plan 

Tailoring Standards. Project Managers may tailor these 
Standards to accommodate unique aspects of projects, as long 
as the resulting approach remains consistent with the 
purpose of this Standard. Any proposed variation to this 
Standard shall be approved on a case-by-case basis by the 
approving authority. Items that shall not be tailored are 
as follows: 

a. Independent Verification/Validation (IV&V) 

b. Configuration Management Requirements 

c. Requirements for software testing 

d. User Requirement Specifications (SRS) 

e. Software Design Documentation (SDD) 


2 


f. Requirements Traceability Matrix (RTM) 


6.1 Tailoring. Tailoring shall be completed only through 
the process of deletion. Tailoring shall not be 
completed by changing or altering these Standards. 


6.2 Tailoring Documentation. Tailoring decisions shall be 
documented in the Software Development Plan. Tailoring 
of any document after the Software Development Plan has 
been approved, shall not be permitted, however a 
deviation/waiver shall be accepted. 


Policies for the Management of Software. The following 
policies apply to the development and management of 
software. Additional information on these policies is 
contained in Sections 1 through 8 of this Standard. 


7.1 Policy. The development and management of software, or 
modifications, (including models), shall follow the 
procedures and policies of this Standard. 


ae The organization developing software shall ensure 
deployability requirements are given primary 
consideration throughout the development process. 
If the requirement for deployability exists, the 
software design shall provide for the immediate 
transition to deployed operation. 


Db: New software shall be developed only upon 
determination that an existing software no longer 
meets, or cannot be economically modified to 
Sacisty functional or user requirements. 
Additvonally, othervagency and Off-the-Shelf 
software shall be evaluated prior to developing 
new software. 


or Computer security, information security, and 
Privacy Act information shall be addressed 
explicitly in each Life Cycle Management Phase. 


d. Economic analyses and budgets prepared for 
software projects shall consider the full range of 
software resources requirements. Reutilization 
and sharing of the existing resources shall be 
considered as alternatives to acquisition of more 
software resources. 


e. Software resource acquisitions shall be planned 
with the objective of achieving the lowest total 
overall cost to the Bureau, price and other 
factors considered. Acquisition strategy will 
normally require full and open competition in 


5) 


10. 


procurement of information technology and purchase 
of equipment. 


&: The choice of programming language shall be 
selected in accordance with user requirements, 
cost effectiveness and reliability. 


Gis Software projects shall not be segmented into 
smaller projects in order to avoid Life Cycle 
Management visibility. Conversely, the scope of 
software projects shall not be defined so broadly 
that management and coordination become unwieldy. 


he Reusable code shall be evaluated and used when 
most appropriate to decrease development cost. 


Project Baseline. Software projects frequently are 
subjective to cost overruns and schedule slippage fora 
variety of reasons, including the changing or addition of 
requirements. While requirement, resources, and schedule 
changes may be unavoidable in some cases, these changes must 
be managed as follows: 


e Project Baselining shall occur for all Bureau software. 


e Project Baselining shall be completed through the 
procedures of Configuration Management. 


e Baseline changes shall be documented and managed 
through the use of configuration control in compliance 
with the Bureau Configuration Management Plan. 


Schedules and Milestones. The Software Developer shall 
provide a development schedule that identifies all events 
such as reviews, audits, key meetings, etc. The schedule 
may be provided graphically. For each activity, the 
schedule shall indicate: 


a. activity initiation, 

| oie. availability of draft and final documentation, 
ee activity completion, and 

d. reas of high risk. 


Facilities. All government, contractor and subcontractor 
facilities (to include physical space, software development 
tools, and documentation) used for computer software 
development for the Bureau shall be open to inspection by 
Quality Assurance personnel upon request. 
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Data Item Descriptions: Deliverable documentation shall be 
delivered in the format specified in the provided data item 
description formats. For smaller software projects, the 
Software Developer may option to use the Consolidated Data 
Item Descriptions (DIDs) provided by this standard but shall 
receive prior approval from the Bureau Project Management 
Board. Bureau Project Management Boards shall not approve 
the use of Consolidated Data Item Descriptions on projects 
ranging from medium to large is size. 


Deliverable Documentation. All required documentation shall 
be delivered on computer diskettes in the format compatible 
with the software Word/Perfect and on 8 1/2" by 11" white 
bond paper. 


11.1 Delivery. All required documents shall be delivered on 
schedule and as a complete and useable document. The 
deliverable schedule for documentation shall depend. on 
the corresponding formal review. Figure 1 identifies 
when each document is to be delivered for first 
review, second review, and approval. 
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Deliverable REVIEWS 


TS Se ee a 


‘_Documents 


System/Segment Specifications 
System/Segment Design 

Software Development Plan 
Software Requirement Specifications 
Interface Requirement Specifications 
Software Design Document 
Software Test Pian 

Interface Design Document 
Resource integration Support 
Software Teet Descriptions 

System Operator Manual 

Software User Manual 

Software Product Specifications 


OO008 868 


Version Description Document 


| RevewCompite [| | | | | | 


: O 1st Review © 2nd Review @ Approval/or Final 
Authority | 


Figure 1. Documentation Schedule for Deliverable Products. 
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SOFTWARE ENGINEERING 


Organization Structure. The software developer shall 
describe the areas of the Organization that will be involved 
in the development effort and identify what tasks will be 
completed by each. 


Personnel. The software developer shall identify the level 
of expertise and capabilities of each person and that 
person’s association with the development effort. 


Software Engineering Environment. The software developer 
shall establish a software engineering environment to 
perform the software engineering effort. The software 
engineering environment shall comply with the security 
requirements of the contract, the statement of work, or the 
task order. The software developer shall document, and 
implement plans for the installation, configuration control, 
and maintenance of each item of the environment. 


Software Development Plan (SDP). The software developer 
shall document and deliver a Software Development Plan using 
the format provided by Data Item Description (DID) BLM 
80030A. The Software Development Plan shall describe the 
software developer’s plan to perform the tasks of software 
development in compliance with this Standard. 


4.1 Approval/Agreement. After final approval is granted by 
the appropriate Project Management Board, the Software 
Development Plan shall become the primary agreement 
between the Software Developer and the Project 
Management Board and shall be used by the Quality 
Assurance Staff to verify compliance with this 
Standard. 


Development Methodology. This Standard shall not discourage 
or specify the use of any particular software development 
methodology but any methodology submitted shall include of 
ten steps listed below and shown in figure 2: 


e System/Segment Design 

e Software Requirements Analysis 

e Preliminary Design 

o- Detailed Design 

e Coding and Unit Testing 

e Integration of Units and Testing 
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e System Testing 


e Interoperability Testing of Interfaces 
e Formal Qualification Test by Quality Assurance 
e Operational Test and Evaluation 


Structured Analysis/Structured Design. The software 
developer shall document, and implement plans for using a 
structured analysis and design, and shall be supported by a 
physical data model. 


Computer Software Organization. The software developer 
shall decompose each Computer Software Configuration Item 
(CSCI) into Computer Software Components (CSCs) and Computer 
Software Units (CSUs). The software developer shall 
ensure that the requirements of the Computer Software 
Configuration Item (CSCI) are completely allocated and 
further refined to facilitate the design and test of each 
Computer Software Components (CSCs) and Computer Software 
Units (CSUs). 


7.1 CSCI Logical Flowchart. The software developer shall 
deliver as part of the Preliminary Software Design 
Document, a Computer Software Configuration Item (CSCT) 
Logical Flowchart itemizing the logical flow of data 
and internal interfaces between Computer Software 
Components (CSCs) and Computer Software Units (CSUs). 


7.2 Inputs, Process, and Outputs. The software developer 
shall deliver as part of the Preliminary Software 
Design Document, a very low level detailed pseudo code 
or narrative description of all inputs, processes, and 
outputs. 


7.3 Data Dictionary. The software developer shall deliver 
as part of the Preliminary Software Design Document, a 
Data Dictionary. 


7.4 Data Model. The software developer shall deliver as 
part of the Preliminary Software Design Document, a 
normalized, fully attributed, characterized, — 
composition access data model. 


7.5 Requirements Traceability. The Software Developer 
shall deliver a Requirements Traceability Matrix at 
each separate step of the software development process 
providing a forward and backward trace of requirements 
from one document to the next. 


Rapid-Prototyping. Rapid-prototyping shall not be part of 
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10. 


11. 


12 


the deliverable product. Rapid-prototyping shall only be 
used for the purpose of validation. Rapid-Prototyping is a 
working miniature of a part of the total design. If it were 
a complete working model of the whole design, it would no 
longer be a rapid-prototype. Therefore, all rapid-prototype 
design shall consider only those aspects which are necessary 
to fulfill the purpose of its creation. 


Software Items. The Software Developer shall identify all 
software items such as special compilers, code auditors, 
analyzers, test drivers, preprocessor, test data generators, 
post processors, etc. The Software Developer shall describe 
the purpose of each, identify the source, and identify any 
classified or security issues. 


Hardware and Firmware Items. The Software Developer shall 
identify the computer hardware, interfacing equipment, and 
firmware items that will be used in the software engineering 
environment. The Software Developer shall describe the ~ 
purpose of each item and shall identify any classified 
processing or security issues associated with the hardware 
or firmware items. 


Quality Assurance. The processes of quality assurance shall 
be independently applied throughout all software development 
by executing the Quality Assurance procedures for 
Developmental Test and Evaluation and conducting a Formal 
Qualification Test. 


Configuration Management. The software developer shall 
Maintain in-house configuration management in compliance 
with the Bureau Configuration Management Plan. 


12.1 Configuration Identification. The software developer 
shall document, and implement plans for performing in- 
house configuration identification. Configuration 
identification shall be conducted in accordance with 
the identification scheme specified in the Bureau’s 
Configuration Management Plan. Configuration 
identification performed by the software developer 
shall accomplish the following: 
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PHASE | CONCEPT DEMONSTRATION | _ PRODUCTION 
EXPLORATION | AND VALIDATION FULL-SCALE DEVELOPMENT AND DEPLOYMENT 
SYSTEM SOFTWARE YSTEM PRODUCTION 
1 REQUIREMENTS | REQUIREMENTS | SOFTWARE DEVELOPMENT | INTEGRATION 
acum |RERLAREMENTS| REQUMEMENTs | SOFTWARE DEvELoPMENT | WIESEATIN | CTAE | snp DEPLOTMENT 
SOFTWARE af 
REQUIREMENT [— — — 
a. . 
= oa DESIGN , =e ‘e 
SOFTWARE | ee ee TRE RIGH: 2) 
ACTIVITY | | a CODING AND . 
, | es ——] UNITTESTING cog Bu 
7 3 — INTEGRATION = 
; 3 ! | AND TESTING | Gsci TESTING 
SYSTEM SOFTWARE PRELIMINARY CRITICAL TEST READINESS _ FUNCTIONAL 
DESIGN SPECIFICATIONS DESIGN DESIGN REVIEW CONFIGURATION 
REVIEW REVIEW REVIEW REVIEW AUDIT 


Figure 2. Software Development Cycle. 
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gg. 


Identify the documentation that establishes the 
functional, Allocated, and Product Baselines, and 
the Developmental Configuration; 


Identify the documentation and the computer 
software media containing code, documentation, or 
both, that are placed under configuration control; 


Identify each Computer Software Configuration Item 
(CSCI) and its corresponding Computer Software 
Units (CSUs); 


Identify the version, release, change status, and 
other identification details of each deliverable 
item; 


Identify the version of each Computer Software 
Configuration Item (CSCI), Computer Software 
Components (CSC), and Computer Software Units 
(CSU) to which the corresponding software 
documentation applies; 


Identify the specific version of software 
contained on a deliverable medium, including all 
changes incorporated since its previous release; 
and 


Provide the sequence numbering for filing items in 
the Software Development Library. 


Configuration Control. The software developer shall 

document, and implement plans for performing in-house 
configuration control in accordance with the Bureau's 
Configuration Management Plan. Configuration control 
performed by the Software Developer shall: 


a. 


establish a Developmental Configuration for each 
Computer Software Configuration Item (CSCI); 


maintain current copies of the deliverable 
documentation and code; 


provide the Bureau of Land Management with access 
to documentation and code under configuration 
control; and 


control the preparation and dissemination of 
changes to the master copies of deliverable 
software and documentation that have been placed 
under configuration control so that they reflect 
only approved changes. 
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13. 


14. 


12.3 Configuration Status Accounting. The Software 
Developer shall document, and implement plans for 
performing configuration status accounting. The 
Software Developer shall generate management records 
and status reports on all products comprising the 
Developmental Configuration and the Allocated and 
Product. Baselines. The status reports shall: 


a. provide traceability of changes to controlled 
products; 
De serve as a basis for communicating the status of 


configuration identification and associated 
software, and 


Cc. serve as a vehicle for ensuring that delivered 
documents describe and represent the associated 
software. 


Software Developer’s Software Development Library. Each 
Software Developer shall establish a Software Development 
Library in accordance with the Bureau Configuration 
Management Plan. All controlling software and associated 
documentation shall reside in this library. The Software 
Developer shall maintain the Software Development Library 
for the duration of the development effort or until the 
deliverables are accepted by the Bureau. 


Software Development Files. Software Development Files 
shall reside in a highly secured Software Development 
Library with access limited to persons responsible for 
maintaining deliverable documentation of all library 
activities. All Software Development Libraries shall be 
open for audits or inspections by the Bureau Quality 
Assurance Office upon request. 


14.1 Documentation. The Software Developer shall: 


e document the development of each Computer Software 
Unit, Computer Software Component, and Computer 
Software Configuration Item in Software 
Development Files (SDFs) ; 


e establish a separate Software Development 
File for each Computer Software Unit or a 
logically related group of Computer Software 
Components; and each Computer Software 
Configuration Item. 


e document and implement procedures for establishing 
and maintaining SDFs. 
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15. 


16. 


e Maintain the Software Development Files for the 
duration of the development effort. The Software 
Development Files shall be made available for 
Quality Assurance Office review upon request. 
Software Development Files may be generated, 
Maintained, and controlled by automatic means. To 
reduce duplication, Software Development Files 
should not contain information provided in other 
documents or Software Development Files. The set 
of Software Development Files shall include 
(directly or by reference) the following 


information: 

a. design considerations and constraints, 

b. design documentation and data, 

e schedules and status information, 

dr test requirements and responsibilities, and 
e. test cases, procedures, and results. 


14.2 Configuration Identification Numbers. Items placed in 
the Software Development Library shall be arranged in 
sequence according to Configuration Identification 
Numbers. 


Coding Standards. The Software Developer shall document, 
and implement coding standards to be used in the development 
of deliverable software. 


15.1 Bureau Coding Standards. Software coding standards 
shall comply with the Bureau Coding Standards when 
available. 


Non-Development Software. The Software Developer shall 
consider incorporating non-developmental software (NDS) into 
the deliverable software. The Software Developer shall 
document plans for using non-developmental software. Non- 
developmental software may be incorporated by the developer 
without the User Representative’s approval only if the non- 
developmental software is fully documented in accordance 
with the requirements of this document. The Software 
Development files need not contain the design 
considerations, constraints, or data. Incorporation of non- 
developmental software shall comply with the data rights 
requirements of the contract, the statement of work, or task 
order. 


16.1 COTS Software. Commercial Off-the-Shelf (COTS) 


13 


smqoleved Srawsio® sit alpine 
st29 Jnanqgoleve® eds 20 meijenee 


bem od Ltpcig eeilt sagamqoleved 


sty's_ enkl2G epasxueas vol iang ‘ 
as tnangqofeyved exawitoB> 
nolteortnen Bbré- bealistoteam 


rewiies \oplsectiquh esube2 
gigjsmoo ton Bb lLuote 
10 eiromsoh 
Stews ise We 
ree~) | 


7. . - - & 
wok STEPS 206 
eam? ~~ ew tt 
“A - - 


Sle iss yo to Yisos 
ottaorgo Sat 
wie opfeah 2 
5b sees | 
| e ‘42 


a2. ,.a 


\jarmvpitasD £.65> 


> iy 


Ssabusts gales 


: Lae) weed cir. 
Paw 2 AAall 
" > _ | ha , 
Cass eS ¢ a j 
‘ Ari 
iw Va Vike 


saldslisves s) 


ftom Juamgeleved -ne! & 
[jszeoqzonal tebteaes? 
jtos sldsteavi led saa 
ims ie Jromuooe 
estce (editemyoleveb, 
398 yea eta suetsiw’ 
I[sjaomgolevsh’ 
7 vrtupez ela dite 
teste ot been sell? snamyoleved 
icleitenos ,acotsassebilenos 
ewitoa ladaemgolevs 

Lo Sinemet 


y >7% 


~ z <4 s » 
ees Pe |i 


L LIAS 


iJ opr InOSD BAa7 


a) 


or 
.ezeadnull 


seoswa 4. 7 


a | 
WE se 


sfort baa 
viteb 36, 
a 


‘inde ¢ ao 


Lis 


18. 


19. 


20. 


21. 


22. 


Software shall be considered Non-developmental 
Software. 


16.2 COTS Software Review. Commercial Off-the-Shelf 
software shall be reviewed as part of the Preliminary 
Design Review. 


16.3 Uses of COTS Software. The Software Developer shall 
incorporate Commercial Off-the-Shelf software to the 
greatest extent possible. 


16.4 Data Flow Diagram. The Software Developer shall 
include Commercial Off-the-Shelf software in the Data 
Flow Diagrams as either a Computer Software 
Configuration Item or Computer Software Component. 


Activity Network. The Software Developer shall implement a 
process for managing the development of deliverable 
software. The software development process for each 
Computer Software Configuration Item shall be compatible 
with the schedule for formal reviews and audits. 


Source Identification. The Software Developer shall 
identify and provide locations for all required resources 
such as software, firmware and hardware. 


18.1 Planning. The Software Developer shall provide a plan 
for obtaining the required resources and shall indicate 
the need date and availability of each item. 


Risk Management. The Software Developer shall document and 
implement procedures for conducting the activities required 
by this document. The Developer shall identify, analyze, 
prioritized, and monitor the areas of the software 
development project that involve potential technical, cost, 
or schedule risk. 


Security. The Software Developer shall document and 
implement security procedures in compliance with the 
Contract, the Statement of Work, or Task Order. 


Interface with Associated Contractors. The Software 
Developer shall document, and implement plans to interface 
with associated contractors for coordinating design and data 
management efforts, to ensure compatibility at interfaces, 
(i.e., where a government agency is developing software 
utilizing outside contractors; where two or more contractors 
are participating in the development or production of the 
software product). 


Interface with Independent V&V Agents. The Software 
Developer shall interface with the Bureau or Bureau 
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23. 


24. 


25. 


26. 


Representative(s) software Independent Verification and 
Validation (IV&V) agent(s) as specified in the Bureau 
Quality Assurance Charter, RFP, contract, Statement of Work, 
or task order. 


Subcontractor Management. The Software Developer shall pass 
down to the subcontractor(s) all contractual requirements 
necessary to ensure that all software and associated 
documentation delivered to the User Representative are 
developed in accordance with the requirements of this 
document. The Software Developer shall provide the 
subcontractor(s) with the baselined requirements for the 
software to be developed. 


Formal In-Process Reviews. During the Software Development 
process the Software Developer shall conduct or participate 
in formal reviews and audits. Guidance on formal reviews and 
audits is provided in the Bureau Software Quality Program 
Plan. During the software development process, the Software 
Developer shall conduct ongoing evaluations of the 
development processes. These evaluations shall include a 
final evaluation of all software and associated 
documentation to assure that all requirements have been met 
and that internal coordination has been conducted. Figure 3 
identifies each document which shall be part of that 
specific review. 


Requirements for Audits and Reviews. The Software Developer 
shall conduct the Functional and Physical Configuration 
Audits. Both audits shall be conducted as a team effort. 
Team members shall include the Bureau Quality Assurance 
Specialist, the Bureau Configuration Management Specialist, 
and Bureau Technical Software Engineering Specialist. 


25.1 Formal Reviews. Formal Reviews shall be held as round- 
table discussion and shall include personnel 
representing the user, technical staff, and Quality 
Assurance. 


25.2 Informal Reviews. Independent informal reviews of 
documentation by selected personnel shall not replace 
formal reviews unless authorization is provided by the 
software’s Bureau Sponsor. 


Corrective Action Process. The Software Developer shall 
document, and implement a corrective action process in 
compliance with the Bureau Configuration Management Plan and 
this Standard. The corrective action process shall serve 
the purpose of correcting errors or problems in the 
developmental stages. 


26.1 Problem/Change Reports. The Software Developer shall 
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26.2 


26.3 


26.4 


prepare a 1260 Problem/Change report to describe each 
problem detected in software or documentation that has 
been placed under configuration control. The 
Problem/Change report shall describe the corrective 
action needed and the actions taken to resolve the 
problem and shall serve as input to the corrective 
action process. 


Classes of Changes. There shall be two separate 
classes of changes: Class I and Class II changes. All 
changes of both classes shall be presented to the 
Configuration Management Board or Configuration 
Management Board Chairman for approval before any 
actions are taken. 


20:22:51 Class I Change. Class I changes shall be 
limited to those which have significant 
impact on the software user’s interface, 
technical performance, efficiency, cost, or 
schedule. All Class I changes shall be 
approved by a Configuration Management Board. 


26.2.2 Class II Changes. Class II changes shall be 
limited minor changes. Class II changes 
shall be no real impact on the software. 
Class II changes do not require board 
approval and may be approved by the 
Configuration Management Board Chairperson. 
These persons shall have the responsibility 
to maintain all associated changes and to 
keep the documentation current as to reflect 
Class II changes. 


Severity and Status Codes. A severity code and a 
status code shall be assigned to each 1260 
Problem/Change Report to reflect the decisions of the 
Configuration Management Board. 


Severity Codes. The severity codes assigned by the 


Configuration Management Board shall indicate the 
following: 
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Severity Code Description 


O01 Hangs up the system 

02 Has no alternative work-around 
03 Has an alternative work-around 
04 Operator inconvenience 

05 No severity assigned 

06 All other errors 


26.5 Status Codes. The Configuration Management Board shall 


26.6 


build a list of status codes to reflect the Board’s 
distribution decisions. These codes shall be used to 
track the activity of each 1260 Problem/ Change Report. 


Distribution. The Configuration Management Board shall 
provide the final distribution of each 1260 
Problem/Change Report. 
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SOFTWARE BEVELORHIENS PHASE 


SYSTEM | SOFTWARE | PRELIMINARY | DETAILED CSCI OT&E 
DESIGN | REQMNTS. DESIGN DESIGN ost. TERT NG INTEG RATION TESTING 
ANALYSIS _ AND TESTING 


‘System/ 
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Spec. 


System/ 
Segment 
Design 
Doe, 
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Software 
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Interface 
Reqmnt. 
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Software 
Develop. 
Plan 


SDR | SRR ; PDR 
Review Review | | Review 
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Test Descrip. 
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Figure 3. 
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SYSTEM REQUIREMENTS DESIGN 


Purpose. The purposes of the System/Segment design are to: 


e review and update the System/Segment 
Specifications document, 


# fully define and validate the functional 
requirements for the system, 


e allocate performance requirements, and 
e design the high-level system (or segment). 


Overview. In the System/Segment Design, all high-level 
functional requirements for the system (or segment) 
identified in the System/ Segment Specifications are fully 
reviewed, and one or more operable systems satisfying the 
performance specifications are designed. The technical 
accuracy of the system design is validated and the best 
design is selected. 


Tasks. The tasks to be completed during this stage of 
development are to: 


e Identify any additional functional requirements of the 
system, 

e Identify Preliminary User Software Requirements, 

e Design the High level System, 

S Develop the Software Development Plan, 

e Develop support plans, 

e Update the Project Management Plan, 

e Develop the System/Segment Design document, 

e Update the System/Segment Specifications Document, and 

° Conduct System/Segment Design Review. 


System/Segment Design Review (SDR). The System/Segment 
Design shall be completed with a successful review of the 
System/Segment Design document. The purpose of the 
System/Segment Design Review shall be to serve as the final 
review before the Software Development Phase begins. The 
System/Segment Design Review is primarily concerned with the 
overall review of the operational/ support requirements 
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(mission requirements), updated and completed System/Segment 
Specifications, allocated performance requirements, and the 
methods, processes, and planning to accomplish the system 
engineering management activities to insure that efforts are 
necessary and sufficient. 


Quality Assurance. Quality Assurance shall include in their 
review: 


e Goroieceness of documentation; 

e Cerise tity Maintainability, and availability; 
e Compatibility with functional requirements; 

e Maintenance support; 

e Logistics; and 

e Risk 


Configuration Management. Upon formal approval and 
acceptance the Software Developer and the Bureau shall each 
place a copy of the System/Segment Specifications Document 
and the System/Segment Design document in the Software 
Development Library and under the control of their 
configuration management. 


Required Documents. The following documents shall be 
required deliverables for review prior to the System/Segment 
Design Review. 


e System/Segment Design Document, 

e Preliminary Software Requirement Specifications, 

e Preliminary Interface Requirement Specifications, and 
e Software Development Plan 


System Specification Requirements. The Software Developer 
shall document the System/Segment Design in the 
System/Segment Design document in compliance with the BLM 
80534 Data Item Description format. 


8.1 Delivery. The Software Developer shall deliver one 
copy of the Systems/Segment Design Document to the 
following agency, section or individual 10 days prior 
to the System/Segment Design Review: 


a. Bureau Quality Assurance Office, and 
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b. Each Review Board Member 


8.2 Functional Baseline. The System/Segment Design Review 
shall be conducted in compliance with the Bureau 
Software Quality Program Plan (77-SQP-000104). 
Following successful completion of the System/Segment 
Design Review and authentication by the appropriate 
Project Management Board, the System/Segment 
Specifications document and the System/Segment Design 
document shall establish the Functional Baseline for 
the Computer Software Configuration Item. 


8.3 System/Segment Design Review. The System/Segment 
Design Review shall be conducted in compliance with the 
Bureau Software Quality Program Plan. The Software 
Developer shall Conduct the System Design Review (SDR). 


8.4 Software Development Plan. The Software Developer 
shall document, and deliver a Software Development Plan 
(SDP) describing their plans for Software Development 
in compliance with this document. The Software 
Development Plan (SDP) shall be documented using the 
BLM 80012A Data Item Description format. The Project 
Management Board approved, SDP shall be placed under 
the control of the Configuration Management Board in 
accordance with the Bureau Configuration Management 
Plan. Changes to the SDP shall receive approval from 
ONLY the Project Management Board. 


System/Segment Specification Requirements. Prior to the 
System/Segment Design, the system functional and performance 
requirements shall be identified and documented in the 
System/Segment Specifications Document in compliance with the BLM 
80008 Data Item Description format. The System/Segment 
Specifications document is generally produced prior to the start 
of a software project to allow management sufficient information 
to provide the authority to continue into the development phase 
or to discontinue all efforts. To be used as the basis for the 
System/Segment Design, the System/Segment Specifications shall be 
delivered an a successful System Resuirements Review (SRR) shall 
be conducted prior to the start of the development phase of a 
project. 


9.1 Delivery. One copy of the System/Segment Specifications 
document to the following agency, section, or individual 10 
days prior to the System Requirements Review (SRR): 

a. Bureau Quality Assurance Office, and 


b: Each SSR Review Board Member 
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SOFTWARE REQUIREMENTS ANALYSIS 


Purpose. The purpose of the Software Requirements Analysis is to 
identify and document the perceived needs of the user, and to identify 
and document each external interface requirement, for both hardware 
and software. 


Overview. The general functional needs, as perceived by the user, 
must be identified and documented in a statement of user requirements. 
User requirements shall provide the basis for software design. Each 
identified and documented requirement shall be addressed and designed 
into the Software Design Document by the Software Developer. 


Tasks. The tasks to be accomplished during the Software Requirements 
Analysis are to: 


e identify and document each user requirement, 
e identify and document each external interface requirement; 
e update the System/Segment Specifications and the System/Segment 


Design Document, if required; and 
e conduct the Software Specifications Review (SSR). 


Scope of the SRS. The Software Requirements Specification (SRS) and 
Interface Requirements Specification (IRS) documents shall clarify the 
intent (level of detail, not subject) and appropriate content, with 
the objective of achieving uniformity and understanding of the 
identified requirements. 


Requirement Content. Each requirement shall be written in a narrative 
form describing the intent of the requirement; each requirement shall 
include a description of the input, processing, output, and method to 
test the requirement; and each requirement shall be supported by a 
logical data model. Data flow diagrams may be included but shall not 
take the place of the narrative. 


Software Specifications Review (SSR). The Software Specifications 
Review shall be a formal review of the requirements for a specific 
Computer Software Configuration Item (CSCI), and each external 
interface requirement to that Computer Software Configuration Item 
(CSCI). The Software Specification Review shall serve as the final 
review and chance to alter, change, or add requirements prior to the 
Preliminary Design. The primary concerns of the Software 
Specifications Review shall be: 


e a functional overview of the Computer Software Configuration 
Item, including inputs, outputs, and processing of each function; 


e overall performance requirements, including those for execution 
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time, storage, and constraints; 


e qualification requirements that identify applicable levels and 
methods of testing of requirements within the Computer Software 
Configuration Item and Interfaces; 


e control flow and data flow between the software functions that 
comprise the Computer Software Configuration Item; 


e quality factors of the document, i.e., correctness; and 
completeness, and testability of each requirement. 


e milestone schedules. 


Quality Assurance. The Quality Assurance staff shall serve as an 
active evaluator throughout the development of the software and 
interface requirements. Quality Assurance shall be included in the 
review of the Software Requirement Specifications and Interface 
Requirement Specifications documents: 


e completeness, correctness, reliability; 

e efficiency, integrity, usability 

e Maintainability, testability, flexibility; 

e reusability, traceability, and interoperability. 


Configuration Management. Upon formal approval and acceptance the 
Software Developer and the Bureau shall place a copy of the Software 
Requirements Specifications document and the Interface Requirements 
Document in their Software Development Library and under the control 
of Configuration Management. 


Required Documents. The following documents shall be delivered prior 
to the Software Specifications Review: 


e Software Requirement Specifications, 
e Interface Requirements Specifications, and 
e Requirements Trace Matrix (RTM). 


Software Analysis Requirements. There shall be a completely defined 
and approved set of engineering requirements for each Computer 
Software Configuration Item before the start of any Software 
Development effort. These requirements shall be documented in the 
Software Requirements Specifications document and shall be in the 
format provided by BLM 80025A. 


10.1 Interface Requirements. There shall be a completely defined and 
approved set of interface requirements for each interface 
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10.2 


10.3 


10.4 


external to each Computer Software Configuration Item. These 
requirements shall be documented in an Interface Requirements 
Specification (IRS), delivered in the format provided by BLM 
30026A, and shall be complete before the start of the development 
errort. 


Evaluation. The Software Developer shall perform evaluations of 
the products to ensure that each requirement described in the 
Software Requirement Specifications and the Interface Requirement 
Specifications can be traced to the System/Segment Specifications 
document and the Software Design document. 


Delivery. The Software Developer shall deliver one copy of the 
Software Requirements Specifications document and one copy of the 
Interface Requirements document (if applicable) to the following 
agency or individuals 10 days prior the Software Specifications 
Review: 


e Bureau Quality Assurance Office, and 
e Each Review Board Member 


Allocated Baseline. The Software Developer shall conduct one or 
more Software Specification Review(s) in accordance with the 
Bureau Software Quality Assurance Program. Following successful 
completion of the Software Specifications Review and approved by 
the User Representative(s), the Software Requirements 
Specification (SRSs) and the Interface Requirements Specification 
Shall establish the Allocated Baseline for the Computer Software 
Configuration Item. 
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PRELIMINARY DESIGN 


Purpose. The purpose of the Preliminary Design is to identify and 
make allocations of computer resources to user functional 
requirements. 


Overview. In the Preliminary Design, all functional requirements for 
the system are fully designed, and one or more operable systems 
satisfying the performance specifications are designed. The technical 
accuracy of the system design is validated and the best design is 
selected. 


Tasks. The following tasks shall be completed during the Preliminary 
Design: 


e design the functional flow embodying all of the requirements 
allocated from the Software Requirements Specifications and 
Interface Requirements Specifications to the individual top-level 
of the Computer Software Configuration Item; 


e identify storage allocation data for each Computer Configuration 
Item as a whole, and describe the manner in which available 
storage is allocated to individual Computer Software Components; 


e identify and design executive control and start/recovery features 
for the Computer Software Configuration Item, including method of 
initiating system operation and features enabling recovery from a 
system malfunction; 


e identify and design the top-level structure of the Computer 
Software Configuration Item; 


e design security, from the security requirements; 


e identify any re-entrancy requirements, and design routines for 
implementing them; and 


e identify support resources; 

e develop the Preliminary Design document; 

e develop the Preliminary Interface Design document; 
e develop the Software Test Plan; and 

e develop an Implementation Plan. 


Preliminary Design Considerations. The commencement of the definition 
and design stage of Software Development is a major event. The 
technical actions required to complete the development are no longer 
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Sequential in nature. From this point in the development process, 
numerous actions will be accomplished concurrently. Following are some 
considerations: 


a. 


Before the software design or redesign is started, the Project 
Manager shall validate and prioritized the functional 
requirements for the software. At a minimum, the functional 
documentation shall specify all system operational requirements 
and provide a detailed description of the functions supported. 


The Project Manager shall review the functional requirements for 
adequacy prior to starting the software design or redesign. All 
gaps shall be filled and all ambiguities clarified to resolve any 
inconsistencies identified in the requirements review. 


Design of new systems, segments of systems, or subsystem shall be 
initiated only after a review of existing items available from 
other agencies and off-the-shelf software that may totally 
Satisfy the functional requirements. 


Complete software designs, including specific objectives and 
performance specifications, shall be prepared for each 
alternative system concept which was supported by the initial 
feasibility studies and economic analyses, and which was 
recommended for detailed evaluation. 


Preliminary Design Review (PDR). The Preliminary Design Review shall 
be a formal review of the Preliminary Software Design Document and 
shall be conducted prior to entry of the Detail Design. Primary 
concerns of the Preliminary Design Review shall: 


e Justification of Life Cycle Cost, 
a Functional Flow, 

e Storage Allocation Data, 

e Design Structure, 

e Security, 

e Re-entrancy (if required), 
° Support Resources, 

e Design Reliability, 

e Design Maintainability, 

° Documentation, and 

e Transportability 
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Quality Assurance Activities. Quality Assurance personnel shall be an 
active participant throughout the Preliminary Design. Quality 
Assurance personnel shall include in their evaluation, at least, the 
following items: 


e Performance 

© Cost 

e Reliability 

e Maintainability 
e Supportability 

e Producibility 

e Transportability 
e Testability 

e Traceability 


Configuration Management. Following successful completion of the PDR 
and authentication by the User Representative(s), the Software 
Developer shall place the Software Design Document in the Software 
Development Library, under the control of the Software Developer’s 
configuration management, in accordance with the Bureau Configuration 
Management Plan (77-CM-000101). 


Software Test Plan. The Software Developer shall document ina 
Software Test Plan, plans for conducting developmental testing in 
compliance with the Bureau Test and Evaluation Master Plan (77-TMP- 
0001.03 ).« 


8.1 Approval. The Software Developer’s Software Test Plan shall be 
subject to approval by the Bureau Quality Assurance Staff. 


8.2 Assumptions and Constraints. The Software Developer shall 
describe any assumptions made in test planning, and any 
constraints imposed upon the CSCI Integration and Testing by the 
Bureau of Land Management, by the Division of Project Management, 
or by any other representative of the Bureau. 


8.3 Quality Program. The Software Developer shall document and 
implement an in-house software quality program in accordance with 
the Bureau Software Quality Assurance Program (SQP), and shall 
adhere to the program for the duration of the development effort. 
The Software Developer’s Software Quality Assurance Program shall 
be delivered to the Bureau’s Quality Assurance office for review 
and approval. 
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Subcontractor Products. The Software Developer shall identify and 
describe plans and procedures for evaluating the adequacy of 
requirements established for subcontractors and for evaluating 
subcontractors products. 


Software Quality Evaluation Records. The software developer shall 
prepare and maintain records of each software product evaluation 
performed. When problems have been identified, a 1260 Problem/ Change 
Report shall be initiated and shall serve as input to the corrective 
action process. The evaluation records shall be available for Bureau 
Quality Assurance review and shall be maintained for the life of the 
development effort. 


Implementation Plan. The Software Developer shall document and 
deliver an Implementation Plan to the Bureau for approval. The 
Implementation Plan shall identify and describe plans for final 
implementation of the software under development, including all 
Commercial Off-the-Shelf software. 


Required Documents. The following documents shall be delivered prior 
to the Preliminary Design Review: 


e Preliminary Software Design Document, 
e Preliminary Interface Design Document, 
bd Software Test Plan, and 

e Implementation Plan 


Preliminary Design Requirements. The Software Developer shall develop 
a preliminary design for each Computer Software Configuration Item and 
shall decompose and partition each Computer Software Configuration 
Item into Computer Software Components in accordance with the Software 
Development methods documented in the Software Development Plan. The 
software developer shall ensure that the requirements identified in 
the Software Requirements Specification document are completely 
allocated and further refined to facilitate the design and test of 
each Computer Software Component. The Developer shall document this 
information in the Software Design Document for each Computer Software 
Configuration Item, and in the format provided by sections 1, 2, 3, 7 
& 8 of BLM 80012A, and shall provide traceability between this 
document and the Software Requirements Specifications. 


13.1 Preliminary Design. The Software Developer shall develop a 
preliminary design for the interfaces external to each Computer 
Software Configuration Item documented in the Interface 
Requirements Specifications. The Developer shall document this 
information in the Preliminary Interface Design document, in the 
BLM 80027A Data Item Description format. 


13.2 Additional Engineering Information. The Software Developer shall 
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13.6 


document in Section 8 of the Software Design Document, for each 
Computer Software Configuration Item, additional engineering 
information generated during the preliminary design process that 
is essential to understand the design. The engineering 
information may include rationale, result of analysis and 
tradeoff studies, and other information that aids in the 
understanding of the preliminary design. 


Testing. The Software Developer shall establish test 
requirements for conducting the CSC integration and testing. The 
Developer’s CSC integration and testing shall include stressing 
the software at the limits of its specified requirements. The 
Developer shall place the test requirements and test results in 
the Computer Software Component Software Development files. 


Software Test Plan. The Software Developer shall develop a 
software test plan (STP) in compliance with the Bureau Test and 
Evaluation Master Plan (TEMP) and the Developer shall submit the 
Software Test Plan to the Bureau Quality Assurance representative 
for approval. Once approved, the Software Developer shall place 
it under the control of configuration management, in accordance 
with the Bureau Configuration Management Plan. 


Delivery. The Software Developer shall deliver one copy of the 
Software Design Document to the following agency or individual 10 
days prior to the Preliminary Design Review: 

e Bureau Quality Assurance Office, and 

e Each Review Board Member 

Preliminary Design Review. The Software Developer shall conduct 


one or more Preliminary Design Review(s) in accordance with the 
Bureau Software Quality Assurance Program. 
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DETAILED DESIGN 


Purpose. The purpose of the Detailed Design is to establish a lower 
level detailed design of the Computer Software Components (CSCs) set 
up in the Preliminary Design and to complete the Software Design 

Document to a detailed level sufficient to allow programmers to code. 


Overview. In the Detailed Design, each Computer Software Component 
designed in the. Preliminary Design is decomposed down into lower level 
Computer Software Units. 


Tasks. The following tasks shall be completed during the Detailed 
Design: 


e Complete the Detailed Design sections of the Software Design 
Document, 

e Develop Test Descriptions, and 

e Submit Test Descriptions to Quality Assurance for approval. 


Detailed Design Considerations. In the Detailed Design, requirements 

from the Computer Software Components are allocated down into Computer 
Software Units of each Computer Software Configuration Item, and shall 
establish the design requirements for each Computer Software Unit. 

The Detailed Design of the external interfaces shall also be designed. 
The following policies are applicable for this design: 


e each CSCI shall be decomposed into testable units which provide 
direct relationship to each higher level component; 


e designs should be based upon the assumption that the software 
will be processed on hardware that is either currently available 
in the Bureau or that has been approved. Acquisition and delivery 
shall have sufficient lead time to allow for use during the 
testing stages of the development phase; 


° software development processes shall provide for Configuration 
Management to facilitate audits and formal reviews, and to place 
strict controls on approved or authenticated documentation; 


e the design shall provide for complete Developmental Test and 
Evaluation processes and shall finish with the Operational Test 
and Evaluation. All testing shall be in compliance with the 
Bureau Test and Evaluation Master Plan; 


e requirements shall be identified for reviews, testing, 
evaluation, and certification of the software, including 
associated times and cost. Proper coordination and adequate lead 
time for support shall be provided for review, test, and evaluate 
organizations. Special emphasis shall be given to third-party 
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review, test, and evaluation requirements, if any; and 


e the Detailed Software Design Document shall be written at a level 
from which the programmer can code. 


Critical Design Review (CDR). The Critical Design Review shall be 
conducted on each configuration item prior to fabrication, production 
and coding to insure that the detailed design solutions are adequate. 
Primary concerns for the Critical Design Review are: 


e gecomposition ofecsc (si; 

e detailed Vegie flow; 

e processing algorithms; 

e allocations of resources; 

e Support functions, i.e., backup, recovery, etc.; 
e design of interfaces; 

e design Reliability; 

e design Maintainability; 

e operator controls; 

e compatibility with requirements; 
e transportability; 

e Maintenance; and 

e testability. 


Quality Assurance. Quality Assurance personnel shall be an active 
participant throughout the Detailed Design process. Quality Assurance 
personnel shall include in their evaluation, the following items: 


e performance, 

e Cost; 

e Reliability, 

e Maintainability, 
e Supportability, 
e PROGUCEDI1Lity, 
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e Transportability, 
e Testability, and 
e Traceability. 


Configuration Management. Following successful completion of the 
Critical Design Review and authentication by the User 
Representative(s), the following updated Software Design Document 
shall be placed under the control of the Software Developer’s 
Configuration Management, in accordance with the Bureau Configuration 
Management Plan. 


® Detailed Software Design Document, 
e Detailed Interface Design Document, and 
e Software Test Descriptions, (Including test cases). 


Required Documents. The following documents shall be delivered prior 
to the Critical Design Review for review: 


e Detailed Software Design Document, 

e Detailed Interface Design Document, and 

e Software Test Descriptions, including test cases. 
e Requirements Trace Matrix (RTM) 


Detailed Design Requirements. The Software Developer shall develop a 
Detailed Design for each CSCI, shall allocate requirements from the 
Computer Software Components to the Computer Software Units of each 
Computer Software Configuration Item, and shall establish requirements 
for each Computer Software Unit. The Developer shall document the 
information in Sections 4, 5 and 6 of the Software Design Document for 
each Computer Software Configuration Item, in the format provided by 
BLM 80012A, and in such detail that the document shall be used to 
create source code. 


9.1 Detailed Design Development. Software Developer shall develop 
the detailed design of the Computer Software Configuration Item 
external interfaces documented in the Interface Requirements 
Specifications. This information shall be documented in the 
Interface Design Document in such detail that the document shall 
be used to create source code. 


9.2 CSC Integration Testing. The Software Developer shall establish 
test responsibilities, test cases in terms of inputs, expected 
results, and schedules for CSC integration and Testing. The 
Developer shall record this information in the Computer Software 
Component, Software Development files in accordance with the 
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Bureau Configuration management plan. 


CSU Testing. The Software Developer shall establish test 
responsibilities, test cases (in terms of inputs, expected 
results, and evaluation criteria), and schedules for testing all 
Computer Software Units (CSU). The CSU testing shall include 
stressing the software at the limits of its specified 
requirements. The Developer shall record this testing 
information in the Computer Software Unit, Software Development 
files in accordance with the Bureau Configuration Management 
Plan. 


Preliminary Qualification Testing. The Software Developer shall 
identify and describe the test cases for the "dry-run" of the 
Formal Qualification Tests identified in the Software Test Plan. 
The Developer shall document this information in the Software 
Test Description for each Computer Software Configuration Item, 
and in the BLM Data Item Description 80015A format. 


Product Evaluations. The Software Developer shall perform 
evaluations of the products identified below and shall present a 
summary of the evaluation results at the Critical Design Review: 


a. Design Document for each Computer Software Configuration 
Item. 

eke The updated Interface Design Document. 

Ce Computer Software Component Test Cases. 

ole Computer Software Unit Test Requirements and Test Cases. 

e. A specified percentage of the set of Computer Software Unit 


and Computer Software Component, Software Development files. 
The specified percentage shall be identified in the Software 
Development Plan. 


tC. The Software Test Description for each Computer Software 
Configuration Item. 


Critical Design Review. The Software Developer shall conduct one 
or more Critical Design Review(s) in accordance with the Bureau 
Software Quality Assurance Program. 


Interface Design Document. The Software Developer shall place 
the updated Interface Design document under the developer’s 
configuration control prior to delivery to the User 
Representative. 


Test Descriptions. The software developer shall place the 
updated Test Description under their configuration control prior 
to delivery to the Bureau’s Quality Assurance representative for 
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Software Detailed Design Document. The software developer shall 
deliver one copy of the Software Detailed Design document to the 


following agency(s) or individual(s) 10 days prior the Critical 
Design Review: 


e Bureau Quality Assurance Office, and 


e Each Review Board Member. 
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Purpose. The purpose of the construction stage of software 
development is to code, integrate, and test the software. 


Overview. This stage begins when the approval for the Critical Design 
Review is granted. It ends when the software has been successfully 
tested by the Developer, and certification is provided by the Quality 
Assurance Staff. 


Tasks. Following are tasks to be completed. 


e Complete program/module coding to support the software. 
e Procure equipment to support the software. 
e Procure any Off-the-Shelf software required to support the 


developed software. 


e Conduct Unit Testing. 

e Conduct the integration of units and test the integration. 

e Conduct the system test. 

e Conduct the Interface Interoperability Test. 

e Conduct the Test Readiness Review (TRR). 

e Validate the system software requirement’s (Formal Qualification 
Test). 

e Certify that the software meets the stated requirements. 

e Conduct the User acceptance test (Operational Test and Evaluation 
(OTE&E)). 

e Obtain approval to implement the system. 


Construction. This stage begins following the approval of all 
documentation presented in the Critical Design Review. The coding of 
units, structuring of data files, and executing the testing procedures 
to ensure the system functions properly and meets the functional and 
user requirements. The following policies are applicable to this 
stage: 


Software Testing. The stages of software testing are as follows: 


e Developmental Verification of standards, procedures and policies; 
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Computer Software Unit (CSU) Testing; 

Computer Software Component (CSC) Integration and Testing; 
System Integration and Testing; 

Interoperability Testing; 

Formal Qualification Testing; and 


Operational Test and Evaluation Testing. 


Figure 4 identifies each test in sequence. 


Sel 


Testing. The Software Developer shall conduct each test as 
identified and describe in the Software Test Plan. With the 
exception of scheduling information, updates to the Software Test 
Plan shall be subject to Bureau Quality Assurance Office 
approval. The Software Developer shall identify each level of 
testing to be conducted in the Software Test Plan. 


Documentation. All documented results of tests conducted by the 
Software Developer shall be made available to the Bureau Quality 
Assurance Staff upon request. 


Computer Software Unit (CSU) Testing Requirements. The software 
Developer shall conduct a software unit test, testing each unit 
separately. 


6.1 


Individual Software Unit Tests. The Software Developer shall 
develop procedures and test cases to individually test each 
software unit. These procedures and test cases shall be placed 
under the Software Developer’s Configuration Management and 
stored in their Software Development library. 


CSU Testing. The software developer shall test each Computer 
Software Unit, ensuring that algorithms and logic employed by 
each Computer Software Unit are correct, and that the Computer 
Software Unit satisfies its specified requirements. The 
Developer shall record the test results of the Computer Software 
Unit testing in the corresponding Computer Software Unit, 
Software Development files. 


Revisions and Retests. The Software Developer shall make all 
necessary revisions to the design documentation and code, perform 
the necessary retesting, and shall update the Software 
Development files of all Computer Software Units that undergo 
design or code changes based on Computer Software Unit tests. 


Source Code Control. The Software Developer shall place the 
source code for each successfully tested, and evaluated Computer 
Software Unit under the Developer’s configuration control, in 
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accordance with the Bureau Configuration Management Plan. 


CSC Integration and Testing Requirements. The Software Developer 
shall conduct the Computer Software Component (CSC) Integration Test. 
The CSC Integration Test shall be a test integrating all Computer 
Software Units within each specific Computer Software Component and 
shall test that Computer Software Component as a whole. Each unit 
designed within a Software Computer Component shall be integrated and 
tested as a Software Computer Component before that test can be 
considered successful. 


7.1 CSC Algorithms and Logic. The Developer shall ensure that the 
algorithms and logic employed by each Software Computer Component 
are correct and that the Software Computer Component satisfies 
its specified requirements. 


7.2 CSC Integration Testing. CSC Integration Testing shall not begin 
until each Computer Software Unit has been successfully tested 
and placed under Configuration Management. 


7.3 Test Results. The results of each successfully tested Software 


Computer Component shall be placed under configuration -management 
to reside in the Software Development Library. 


aa 


, fe 
ale. te 
hamepsned cobiesveiShoo BAeaie ety date ‘eit 


sxeWwI208 at .s7 cenesinped oattnet bare TOLD e Jai. 
“ 12) lo”—qnecD azewJIOR xsdvamnd Sad evant 380 

B oe seven? iso) 6 od {sede tas? nore gail 

=YEWw2702 tesyemoD aftthoegs tose aifdtiw agkauis 

dw 6 38 teanoqmoD agewitee TeitugmoD per Jao. 

[isde ito4nogittoD tstinniod etswiiod £ oid iw oe oot 

4 svotecd clark YCTEEN re54 qmad SiBwI IOS & 8S De, 

_Iutassonve Dhortess 


wre i fee eqoieved aq teed bee eants Poop ias DBD 
: 2 dose | Sevoigme ofpol has aes iropis 
5:5 rm 5 edz tends Bas JIoet1od Sis 
wremesiypoy beliiosqe egek 


229 veltnaoT scoltexrpegal 982 
)) esawt3ot sesyvamod toss Ligaen 
itex iacD webas beosiq Dae 


af t igi aiiveok Janet 
1D TOI. Ys 5{ rconog 
“a3 1c ablest oF" 


oe 


DEVELOPMENTAL TEST AND EVALUATION 


' SOFTWARE ss: , 
SYSTEM/SEGMENT : REQUIREMENTS: ' PRELIMINARY | DETAILED | CODING 8 CSC | 
DESIGN | DESIGN | DESIGN ;_ UNIT: INTEGRAT ION: CSCI FQT 
| DEFINITION : ' TESTING : AND TESTING | | TESTING | 


VERIFICATION OF STANDARDS 


f VAU DATION \ 
/ REQUIREMENTS : 


Figure 4. Software Development Testing Requirements. 


7.4 Software Development Files. The Software Developer shall record 
the test results of all CSC Integration and Testing in the 
corresponding Software Development Files. 


7.5 Revisions and Retests. The Software Developer shall make all 
necessary revisions to the design documentation and code, perform 
the necessary retesting, and shall update the Software 
Development files of all Computer Software Units, Computer 
Software Components, and Computer Software Configuration Items 
that undergo design or code changes, based on the results of the 
testing performed. 


7.6 Procedures. For each test case identified in the Test 
Descriptions the Software Developer shall develop procedures for 
the setup, procedures for conducting each test, and procedures 
for analyzing the test results. This procedure shell be 
documented in the Software Test Description for each Computer 
Software Configuration Item. 


7.7 Source Code Control. The Software Developer shall place the 
source code for each successfully tested and evaluated Computer 
Software Component under the Developer’s configuration ‘control, 
in accordance with the Bureau Configuration Management Plan. 


CSCI Integration and Testing Requirements. The Software Developer 
Shall conduct and document the Computer Software Configuration Item 
test. The Computer Software Configuration Item test shall be an 
integration of all Computer Software Components, to test the Computer 
Software Configuration Item as a whole. 


8.1 CSCI Testing. The CSCI Test shall not be conducted until after 
all CSCs have been completely and successfully tested and the 
results of the test placed under configuration control in 
accordance with the Bureau Configuration Management Plan. 


8.2 Preliminary FQT. The Computer Software Configuration Item test 
shall be a preliminary test ("dry-run") of the Formal 
Qualification Test. During the time the Preliminary 
Qualification Tests (PQT) are being conducted, files and source 
code shall not be altered in any way. 


8.3 Testing Results. All Computer Software Components shall be 
successfully tested and the results of the tests placed under 
Configuration Management, to reside in the Software Development 
Library before this test is considered complete. 


8.4 PQT Responsibilities. The Software Developer shall conduct the 
Preliminary Qualification Testing activities as documented in 
their Software Test Plan. Supervision of the Preliminary 
Qualification Testers shall not be the same person who developed 
the software. This does not preclude members of the Software 
Development team from participating in the Preliminary 
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8.11 


Qualification Test activities. 


Testing of Requirements. The Software Developer shall provide 
adequate test coverage of requirements. This means 1) that every 
specified requirement in the Software Requirements Specifications 
document shall be addressed by at least one test; 2) test cases 
have been selected for both "average" situation and "boundary" 
Situations, such as minimum and maximum values; 3) "stress" 
cases have been selected, such as out-of-bounds values; and 4) 
test cases: that exercise combinations of different functions 
Shall be included. 


Adequacy of Test Cases and Procedures. The Software Developer 
Shall provide an adequacy of test cases, test procedures, test 
inputs, expected results, and evaluation criteria. Test cases 
and test procedures shall specify exactly what inputs to provide, 
what steps to follow, what outputs to expect, and what criteria 
to use in evaluating the outputs. If any of these elements are 
not specified, the test case or test procedure is inadequate. 


Completeness of Testing. The Software Developer shall provide 
completeness of testing. Testing shall be complete if ‘all test 
cases and all test procedures have been performed, all results 
have been recorded, and all acceptance criteria have been met. 


Completeness of Re-Testing. The Software Developer shall provide 
completeness of retesting. Retesting shall consist of repeating 
a subset of the test cases and test procedures after software 
corrections have been made to correct problems found in previous 
testing. Retesting is considered complete when: 1) all test 
cases and test procedures that revealed problems in the previous 
testing have been repeated, their results have been recorded, and 
the results have met acceptance criteria, and 2) all test cases 
and test procedures that revealed no problems during the previous 
testing, test functions that are affected by the corrections, 
have been repeated, their results have been recorded, and the 
results have met acceptance criteria. 


Revisions and Retesting. The Software Developer shall make 
necessary revisions to the Software Design Document(s) and code; 
conduct all necessary retesting; and update the Software 
Development files of all Computer Software Units, Computer 
Software Components, and Computer Software Configuration Items 
that undergo design or coding changes based on the results of the 
Formal Qualification Testing. 


Revisions After FQT. The Software Developers shall make 
necessary revisions to the Interface Design Document based on the 
results of Formal Qualification Testing and shall prepare the 
Interface Design Document for delivery. 

Documentation. The Software Developer shall develop and deliver 


40 


eatuivisos ses? dbase Eisiaag 
uped to pelsaokr 
‘aed sseupebs 
past bei iioege 
SB BO 4308 Sheemimeap 

bstoe lee need even 
stjauaie 


yFesbD 


wm § 


a & 


IAL 


J 19 S CG BI os Vi 


ad 


Tamar. 


Te pane 


» [qareD 


, ee Poe 


- me 


colratnanyse® 


1 
ean 
5 
A 


the following software support and operational documentation: 


e Computer Resources Integrated Support Document, 

e Computer Systems Operators Manual, 

bd Software User"s Manual, 

e Software Programmer"s Manual, and 

e version Description Document. 

Testing interface Requirements. The Software Developer shall 


provide adequate test coverage of interface requirements to 
include: 1) that every specified requirement in the Interface 
Requirements Specifications document shall be addressed by at 
least one test; 2) test cases have been selected for both 
"average" situation and "boundary" situations, such as minimum 
and maximum values; 3) "stress" cases have been selected, such as 
out-of-bounds values; and 4) test cases that exercise 
combinations of different functions be included. 


Adequacy of Test Cases and Procedures. The Software Developer 
shall provide an adequacy of test cases, test procedures, test 
inputs, expected results, and evaluation criteria. Test cases 
and test procedures shall specify exactly what inputs to provide, 
what steps to follow, what outputs to expect, and what criteria 
to use in evaluating the outputs. If any of these elements are 
not specified, the test case or test procedure is inadequate. 


Completeness of Testing. The Software Developer shall provide 
completeness of testing. Testing shall be complete if all test 
cases and all test procedures have been performed, all results 
have been recorded, and all acceptance criteria have been met. 


Completeness of Retesting. The Software Developer shall provide 
completeness of retesting. Retesting shall consist of repeating 
a subset of the test cases and test procedures after software 
corrections have been made to correct problems found in previous 
testing. Retesting is considered complete when: 1) all test 
cases and test procedures that revealed problems in the previous 
testing have been repeated, their results have been recorded, and 
the results have met acceptance criteria; and 2) all test cases 
and test procedures that revealed no problems during the previous 
testing, but for which test functions that are affected by the 
corrections, have been repeated, their results have been 
recorded, and the results have met acceptance criteria. 


Revisions and Re-Tests. The Software Developer shall make 
necessary revisions to the Interface Design Document(s) and code, 
conduct all necessary retesting, and update the Software 
Development Files of all Computer Software Units, Computer 
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Software Components, and Computer Software Configuration Items 
that undergo design or coding changes based on the results of the 
formal qualification testing. 


8.17 Revisions to Documentation and Code. The Software Developer 
Shall make necessary revisions to design documentation and code, 
and shall perform all retesting based on System Integration and 
Testing. 


8.18 System Integration and Test. The Software Developer shall 
Support the development and documentation of system integration 
and test plans, test cases, and test procedures. 


8.19 Post-Test Analysis. The Software Developer shall support post 
test analysis and reporting of System Integration and Test 
results. 


8.20 Baseline Documentation Changes. The Software Developer shall 
prepare necessary changes to baselined documentation. 


Interoperability Testing Requirements. The Software Developer shall 
test each interface identified and documented in the Interface Design 
Document to validate the requirement. Each interface shall be 
successfully tested and the results of the tests placed under 
Configuration Management to reside in the Software Development 
Library. 


Test Readiness Review (TRR). The Software Developer shall conduct one 
or more Test Readiness Review(s) in accordance with the Bureau 
Software Quality Assurance Program. 


10.1 Developer’s Readiness Status. The Test Readiness Review shall be 
a formal review of the Developer"s readiness to begin the Formal 
Qualification Testing. It is conducted after all informal 
testing is successfully completed in compliance with the 
developer"s approved test plans and shall be completed prior to 
Formal Qualification Testing. 


10.2 Quality Assurance Personnel. Quality Assurance personnel shall 
be an active participant in the Test Readiness Review and shall 
provide approval to proceed into the Formal Qualification 
Testing. 


10.3 Test Readiness Review. Test Readiness Review shall be conducted 
only after a Computer Software Configuration Item system test and 
Interoperability test has been successfully completed. 


Formal Qualification Testing Requirements. The Formal Qualification 
Test shall be monitored by an independent Quality Assurance Staff and 
shall begin after a successful Test Readiness Review, and after the 
Quality Assurance Staff is satisfied that the software is ready. A 
formal report shall be submitted documenting each test result. The 
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Formal Qualification Test shall validate each requirement documented 
in the Software Requirements Specifications and Interface Requirements 
Specifications documents. When the Formal Qualification Test and the 
Functional Configuration Audit (FCA) can serve as one, then the 
Functional Configuration Audit shall not take place. 


11.1 User Requirements Validation. Each User requirement documented 
in the Software Requirements Specifications document shall be 
validated during the Formal Qualification Testing. 


11.2 Certification. After a complete and successful Formal 
Qualification Test, the Quality Assurance Staff shall provide 
certification that the software operates correctly and that user 
requirements are satisfactorily met. 


11.3 Formal Qualification Tests. The Software Developer shall support 
the Formal Qualification Test and be available during the tests 
to provide needed assistance. 


Operational Test and Evaluation (OT&E) Requirements. The user shall 
conduct the Operational Test and Evaluation test in an environment as 
close to operational as possible. Only errors detected that’ support 
requirements shall be corrected. There shall be no additions to 
requirements nor changes to requirements as a result of these tests 
until after implementation. 


12.1 User Acceptance. The operational test and evaluation shall be a 
user acceptance test executed in an environment as operational as 
possible. Deficiencies found during the OT&E that do not 
validate documented requirements shall be corrected. 

Alterations, changes, or additions to the documented requirements 
in the Software Requirement Specifications, shall not be 
authorized. 


12.2 Successful OT&E. A successful Operational Test & Evaluation 
shall be completed before all or part of the software is to be 
released for deployment and implementation. 


12.3 Second Phase of FQT. An Operational Test and Evaluation shall be 
conducted prior to the deployment of software and shall be 
conducted after the second phase of the Formal Qualification 
Test. 


12.4 Developer Support. The Software Developer shall support the 
Operational Test and Evaluation. 


Quality Assurance. Bureau Quality Assurance Staff personnel shall 
conduct Independent Verification and Validation tasks throughout the 
Software Developmental Test and Evaluation phase. 


Configuration Management. Each successfully tested Computer Software 
Unit and Computer Software Component shall be placed under 
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4 configuration control and stored in the Software Development 
® Library/Files along with the test cases and results of each test. 
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FORMAL QUALIFICATION TESTING 


Purpose. The purpose of conducting the Formal Qualification Testing 
(FQT) shall be to validate each requirement identified and documented 
in the Software Requirements Specifications document and the Interface 
Requirements Specifications document. 


Overview. The Formal Qualification Test shall be conducted by the 
Software Developer and witnessed by the Bureau Quality Assurance Staff 
and shall be conducted after the Software Developer has completed a 
successful preliminary dry-run, and after a successful Test Readiness 
Review. The Formal Qualification Test shall begin only after the 
Bureau Quality Assurance Staff verifies that the software is ready for 
Formal Qualification Testing. 


Task. The following tasks must be accomplished during this stage: 


a. All software documentation including source code, test 
descriptions, requirements, and design documents shall be turned 
over to the Bureau Quality Assurance Staff for testing and 
evaluation. 


DD. Errors and problems detected during the first phase of the Formal 
Qualification Test shall be corrected. 


Ch Corrections shall be retested. 


d. Bureau Quality Assurance Staff shall provide recommendations to 
field the software; to field the software with modifications; or 
not to field the software. 


Software Developer’s Support Personnel. The Software Developer shall 
provide the Bureau Quality Assurance Staff with names and skill levels 
of personnel who will be supporting the Formal Qualification Testing. 


4.1 Unique Requirements. The Software Developer shall specify any 
requirements unique to a particular position, such as required 
security level, extended hours, etc. 


Test and Evaluation Master Plan (TEMP). The Formal Qualification Test 
shall be conducted in compliance with the Bureau Test and Evaluation 
Master Plan, and shall reflect the current Developmental Test and 
Evaluation, to include performance, functional requirements, user 
requirements, and interface requirements using the evaluation criteria 
defined in the Test and Evaluation Master Plan. 


Test Approach/Philosophy. The Formal Qualification Test shall be 
conducted in two phases, with sufficient time between phases to allow 
correction of errors and problems detected in Phase One. Phase Two 
shall be conducted to retest errors and problems detected in phase 1. 
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Software Review Board Meetings. Bureau Quality Assurance Staff 
personnel shall conduct formal Software Review Board meetings during 
the Formal Qualification Test. These meets shall be supported by the 
user representative and the Software Developer. 


Traceability of Requirements to Software Design Document Test Cases. 
Quality Assurance personnel shall verify the traceability of the 
requirements in the Software Requirements Specifications and the 
Interface Requirements Specifications that are satisfied or partially 
Satisfied by each test case identified in the Software Test 
Descriptions as related to the Software Design Document. The Software 
Developer shall document this traceability in the Software Test 
Description for each Computer Software Configuration Item so each test 
case can be traced back to the specific design of a requirement in the 
Software Design Document. 
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ie Deployment and Implementation 
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Purpose. The purpose of the deployment and implementation step is to: 


e implement the software per the Implementation Plan that was 
developed and approved during the Preliminary Design, and 
e deploy the software to each approved location. 


Overview. Deployment and implementation of software are well planned 
and documented activities involving each deployment site 


Tasks. The tasks to be performed during this step of development are: 


e Train user and ADP personnel in the use and operations of the 
software, and 


e deploy and implement the software at all operating sites. 


Implementation. The ability to effectively implement software is 
dependent upon the quality of the implementation procedures developed 
during the definition and design steps and the subsequent exécution of 
these procedures by the implementation team. 


General Guidelines. The following guidelines are provided to assist 
the Project Manager in successfully implementing the software: 


a. Review the documents that will be used during the implementation 
phase (specifically the Implementation Plan) to ensure accuracy, 
compliance with development standards, and compatibility with 
other software documents. 


b. Conduct a final review before beginning any implementation 
actions to ensure that manuals have been distributed, supplies 
are in place, sites are ready, computer resources are available, 
and that personnel have been trained to support the 
implementation. 


Cc: Provide a copy of the Implementation Plan to each site well in 
advance of the scheduled implementation date, to ensure that each 
Site will be prepared to commence software implementation on 
schedule without conflicting priorities, personnel and equipment. 
Additionally the Project Manager should schedule extensive 
briefings regarding impact of implementation. 


Audits. The Software Developer, in the presence of the Quality 
Assurance personnel, shall conduct a Functional Configuration Audit 
and a Physical Configuration Audit. 


Product Baseline. After the Quality Assurance Staff completes the 
inventory of the Product Baseline, the Product Baseline is turned over 
to the User Representative or Owner of the software to be placed under 
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10. 


the Owner’s controlling Configuration Management Board. 


Completion. This step shall be completed when the software has been 
successfully deployed and implemented at each designated site. 


Quality Assurance. The Quality Assurance Staff along with the 
software developer shall conduct an inventory of the Product Baseline 
to ensure that all documentation is complete and available. Quality 
Assurance shall verify implementation procedures and the functionality 
of the software after implementation. 


Configuration Management. At the conclusion of implementation, the 
Product Baseline shall be turned over to the Owner/User of the 
software or that User’s Representative and shall be placed under the 
control of a Configuration Management Board with a User Representative 
as the Board Chairperson. This Board shall process all trouble 
reports for maintenance or modifications. 


10.1 Software Developers Support of CCBs. The Software Developer 
Shall support the User’s Configuration Management Board by 
providing Technical Representatives to assist that Board in 
distributing changes and modifications. Final Board deéisions 
Shall be provided by the Board Chairperson. 
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Operations and Maintenance 


Purpose. The purpose of the Operations and Maintenance Phase of the 
Life Cycle is to operate the software, and maintain changes and 
modifications as authorized by the Configuration Management Board. 


Overview. After implementation, software changes and modifications 
are performed against the software baseline via request to a User 
controlled Configuration Management Board which distributes each 
request after review and discussion. 


Tasks. The tasks to be performed during this step of development are: 


a. to operate the software, 

be conduct Configuration Management Board meetings where: 
Lee New 1260 Trouble Reports are reviewed and distributed, 
zi, Completed 1260 Trouble Reports are closed out, and 

6. to review operational software at regular intervals. 


Completion. This phase of the life cycle is completed when the 
decision is made to terminate or replace the software. 


Change/Modification Controls. Changes and modifications shall be made 
only if the software does not meet a mission requirement and only if 
change is more cost-effective than the development of new software; or 
when a cost savings can be shown; or when a new requirement has been 
imposed by the User/Owner. The decision regarding changes and 
modifications to software shall be made by the Chairperson of the 
controlling Configuration Management Board upon submission of the 
problem to that board. 


Change Justification/Approval. Maintenance and modification projects 
Shall be justified, approved, and prioritized in order to balance 
available resources. Justification, approval, and DElOLita zation 
shall be the responsibility of the Configuration Management Board 
whose Chairperson shall be a User Representative. 


Trouble Reports. All requests for maintenance and modifications to 
software shall be supported by a documented Trouble Report (BLM 1260). 
Only one incident shall be described per report. Each Trouble Report 
shall be complete when submitted to the Configuration Management Board 
Bor action . 


7.1 Documentation of Errors/Problems. When programmers or analysts 
detect other errors or problems while completing an assignment 
identified on an approved Trouble Report, they shall document 
those errors or problems on another Trouble Report, to be 
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submitted to the Configuration Management Board for action. 
Those errors or problems shall not be corrected until presented 
to the Configuration Management Board for approval. 


Life Cycle Management. Maintenance, development, and modification 
projects shall proceed completely through each phase of the LCM 
process, regardless of the level of change or modification. All 
documents effected by the change or modification, specifically the 
Software Requirements Specifications, Software Design Document, and 
the Software Test Description, (including test cases) shall be 
reviewed and updated to reflect the change or modification. 


Termination. Operational software which no longer serves a valid need 
Shall be terminated by the software owners through the actions of the 
Configuration Management Board. This normally occurs when a 
replacement becomes operational; however, instances May arise when the 
requirements no longer exist, or do not justify the reoccurring 
expense of operating and maintaining the software. 


Quality Assurance. The Quality Assurance Staff shall conduct 
verification and validation of each software after change or 
modification AND prior to the software being placed in an opérational 
status. It shall be a Quality Assurance Staff responsibility to 
verify each document requiring update, and to validate functionality 
of changes or modifications. 

Configuration Management. All items placed under the control of the 
Owner"s Configuration Management Board shall be removed only with 
authorization of the Board"s action. Only items required to make 
specific corrections or modifications shall be authorized for release 
from the Software Development Library. All Configuration Management 
actions shall be in compliance with the Bureau Configuration 
Management Plan. 
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ROCUMENT : 


PURPOSE: 


CONTENTS : 


BLM 80033B 


SOFTWARE SUPPORT PLAN (SSP) 


The Software Support Plan (SSP) provides the information needed 
to plan for life cycle support of deliverable software. 


The SSP documents the contractor’s plans for transitioning 
support of deliverable software to the support agency. 


Paragraphs that have been tailored out of the DID shall result in 
the corresponding paragraph number and title in the document, 
followed by "This paragraph has been tailored out." 


Content requirements. Content requirements begin on the 
following page. The numbers shown designate the paragraph 
numbers to be used in the document. Each such number is 
understood to have the prefix "10.2" within this DID. For 
example, the paragraph numbered 1.1 is understood to be. paragraph 
POe2ei 1. within. this DID. 


Document Structure: 


Le Scope 
iis LOeCnCiTication 
1.2 System 
1.3 Document overview 


23 Referenced documents 
3 Software support resources 
3.1 Facilities 
3.2 Hardware 
3.3 Software 
3.4 Data 
3.5 Other documentation 
3.6 Personnel 
3.7 Other resources 
3.8 Interrelationship of components 


4. Recommended procedures 

by Training 

6) Anticipated areas of change software. 
dh Transition planning 

8% Notes 

9. Appendixes 
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Scope. This section shall be divided into the following 
paragraphs. 


Identification. This paragraph shall contain a full 
identification of the system and the CSCIs to which this document 
applies, including, as applicable, identification number(s), 
title(s), abbreviation(s), version number(s), and release 
number(s). . 


System overview. This paragraph shall briefly state the purpose 
of the system and the software to which this document applies. 
It shall describe the general nature of the system and software; 
summarize the history of system development, operation, and 
Maintenance; identify the project sponsor, user, developer, and 
support agencies; identify current and planned operating sites; 
and list other relevant documents. 


Document overview. This paragraph shall summarize the purpose 
and contents of this document. 


Referenced documents. This section shall list by document number 
and title all documents referenced in this document. This 
section shall also identify the source for all documents not 
available through normal Government stocking activities. 


Software support resources. This section shall be divided into 
paragraphs to identify and describe the resources required to 
support the deliverable software. These resources shall include 
items necessary to control, copy, and distribute the software and 
its documentation, and to specify, design, implement, document, 
Pest, mevaluatesacontrol;ecopy, and distribute!’ modifica*stions to 
the software. 


Facilities. This paragraph shall describe the facilities 
required to support the deliverable software. These facilities 
may include special buildings, rooms, mock-ups, building features 
such as raised flooring or cabling; building features to support 
security and privacy requirements (TEMPEST shielding, vaults, 
etc.), building features to support safety requirements (smoke 
alarms, safety glass, etc.), special power requirements, and so 
on. The purpose of each item shall be described. Diagrams may 
be included as applicable. 


Hardware. This paragraph shall identify and describe the 
hardware and associated documentation necessary to support the 
deliverable software. This hardware may include computers, 
peripheral equipment, hardware simulators, stimulators, 
emulators, diagnostic equipment, and non-computer equipment. The 
description shall include: 


a. Specific models, versions, and configurations, and 
acceptable alternatives 
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b. Rationale for the selected hardware 
a A figure showing the interrelationship of the hardware 


a Reference to user/operator manuals or instructions for each 
item, as applicable 


e. Identification of each hardware item and document as 
Government furnished, an item that will be delivered to the 
support agency, an item the support agency is known to have, 
an item the support agency must acquire, or other 
description of status 


Ee If items must be acquired, information about where to 
acquire them 


a Security and privacy considerations, limitations, or other 
items of interest 


Software. This paragraph shall identify and describe the 
software and associated documentation required to support the 
deliverable software. This software may include computer-aided 
software engineering (CASE) tools, compilers, test tools, 
simulations, emulations, utilities, configuration management 
tools, and other software. The description shall include: 


a. Specific names, identification numbers, version numbers, 
release numbers, and configurations, as applicable, and 
acceptable alternatives 


b.. Rationale for the selected software 
(avr A figure showing the interrelationship of the software 
d. Reference to user/operator manuals or instructions for each 


item, as applicable 


e. Identification of each software item and document as 
Government furnished, an item that will be delivered to the 
Support agency, an item the support agency is known to have, 
an item the support agency must acquire, or other 
description of status 


£. If items must be acquired, information about where to 
acquire them 


g. Security and privacy considerations, limitations, or other 
. items of interest 


Data. This paragraph shall identify and describe the data and 
associated documentation required to support the deliverable 
software. This data may include CASE tool repositories, test 
data, configuration and other databases/data banks, and other 
data. The description shall include: 
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a. Specific names, identification numbers, version numbers, 
release numbers, and configurations, as applicable, and 
acceptable alternatives 


bz Rationale for the selected data 
ce A figure showing the interrelationship of the data 
ae Reference to user/operator manuals or instructions for each 


item, as applicable 


e. Identification of each identified item and document as 
Government furnished, an item that will be delivered to the 
Support agency, an item the support agency is known to have, 
an item the support agency must acquire, or other 
description of status 


Le If items must be acquired, information about where to 
acquire them 


Gg: Security and privacy considerations, limitations, or other 
items of interest 


Other documentation. This paragraph shall identify any other 
documentation needed to support the deliverable software. The 
list will include, for example, plans, reports, studies, 
specifications, design documents, test cases/procedures, test 
reports, user/operator manuals, and support manuals for the 
deliverable software. This paragraph shall provide: 


a. The name, identification number, version numbers, release 
numbers, as applicable, and acceptable alternatives, if any, 
for each document 


De Rationale for including each document in the list 
ce A figure showing the interrelationship of the documents 
role Identification of each document as Government furnished, an 


item that will be delivered to the support agency, an item 
the support agency is known to have, an item the support 
agency must acquire, or other description of status 


e. If a document must be acquired, information about where to 
acquire it 


Ee Security and privacy considerations, limitations, or other 
items of interest 


Personnel. This paragraph shall describe the personnel required 
to support the deliverable software, including anticipated number 
of personnel, types and levels of skills and expertise, and 
security clearances. This paragraph shall cite, as applicable, 
actual staffing on the development project to estimate how to 
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staff the support effort. 


Other resources. This paragraph shall identify any other 
resources required to support the deliverable software. Included 
may be consumables such as magnetic tapes and diskettes, together 
with an estimate of the type and number that should be acquired. 


Interrelationship of components. This paragraph shall identify 
the interrelationships of the components identified in the 


preceding paragraphs. A figure may be used to show the 
interrelationships. 


Recommended procedures. This section shall be divided into 
paragraphs as needed to describe any procedures that the 
contractor may wish to recommend to the support agency for 
supporting the deliverable software. Included may be procedures 
for software support management, software engineering, software 
testing, software product evaluations, software configuration 
management, or other activities. 


Training. This section shall be divided into paragraphs as 

appropriate to describe the contractor’s plans for training 

personnel to manage and implement support of the deliverable 
software. This section shall include: 


a. The schedule, duration, and location for all required 
training 
ley The delineation between classroom training and "hands-on" 
training 
ae Provision (either directly or by reference) for: 
1) Familiarization with the operational software and 
target computer (s) 
a) Familiarization with the support software and host 
system 
oi) Equipment maintenance procedures, as applicable 


Anticipated areas of change. This section shall describe 
anticipated areas of change to the deliverable software. 


Transition planning. This section shall be divided into 
paragraphs as needed to describe the contractor’s plans for 
transitioning the deliverable software to the support agency. 
This section shall address the following: 


a. All activities to be performed to transition the deliverable 
software to the support agency. These activities may 
include planning/coordination meetings; preparation of items 
to be delivered to the support agency; packaging, shipment, 
installation, and checkout of the software support 
environment; packaging, shipment, installation and checkout 


— 


Be, 


of) 


feb sit srogque o7 Kevippet sesaten 


inh O14 Bette ej Ty 3 Siz 7. ejsmisae re cjiw 


ogme> ecs to eqidanoltalextsigk adZ 


mgioe ,pilpedoag ;Jaaenoshvas 


ee a - a) To 


.saotte osoaque ais ti ig! 


“8 fosybet BIfQ GINT .Bso% Otsey ee tee 


—STPSn BS Mou” as ldsmuBion. pm ae 


. 2penocsy 10 uisedolislexaeiay 


© a ae : A Bist +h rps 789 paitheos's 
.Roirit ino Lis. 09% ToL 


| SUSI bebrsmpooms 
1290 oF bse deen" es ani TeSIEQ 
; ug? + telw veo zcuoei20605 
a Sievii60 679 palyzogate 

| eel rT ToOuqVe OxsWy lose see 
fi horqg srswIIos ociees3 

Le 5 Wery ) , J uamepsetan 


j i f fy { A: r1sq 
F s pe ctr = Aw > } - 
1WjIDF 7a 
TG Li 4 
- Zz gat! ts 
2 ‘oy 5 ! 
) 
hs i] [ 
* 
‘ a a 
\ . os 
— 
< 
=, CF 
} iF ap.) Oral 
cry Pe 
= a! oe ie, =n] thet. 
‘ 
: : “poe = . s. 14 4 pe | 
| 
} rs ‘oie | r 
- bare. ~, aed ¢ ES ines 2 a 
| 381 MW af eatosips 
7 , we A oe } - 
BS : [ Ml] a) IT acexr7 


| enerdba Liade notsaseq, eld? 


Tq 90. O93 S@LILVigJos Iisa -& 


ce ITOOQQUVE SH? oF stausios 
IENLIPOS \palsisiaq eby Tonal 
é . =a a - » F 5 — ~ 
sO ty N2 oF9 besyseviltet sd oJ 
10G715eSis brie OL ABS CRIs 


of the operational software; and training of support 


personnel. 

Dy Roles and responsibilities for each activity 

(ana The resources necessary to carry out the transition 
activities and the source from which each resource will be 
provided 

A Schedules and milestones for conducting the transition 


activities. These schedules and milestone shall be 
compatible with the contract master schedule. 


e. Procedures for installation and checkout of the deliverable 


software in the support environment designated by the 
contracting agency 


Notes. This section shall contain any general information that 
aids in understanding this document (e.g., background 
information, glossary). This section shall include an . 
alphabetical listing of all acronyms, abbreviations, and their 
meanings as used in this document and a list of any terms and 
definitions needed to understand this document. 


Appendixes. Appendixes may be used to provide information 
published separately for convenience in document maintenance 
(e.g., charts, classified data). As applicable, each appendix 
shall be referenced in the main body of the document where the 
data would normally have been provided. 
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DOCUMENT: BLM 80034B 


COMPUTER CENTER SOFTWARE OPERATOR MANUAL 


PURPOSE: The Computer Center Software Operator Manual (CCSOM) 
provides personnel in a computer center a detailed 
operational description of a software system, its 
operating environment, and procedures for performing 
computer runs of the system. 


A CCSOM is developed for software systems that will be 
installed in a computer center, with users accessing 
the system via terminals or submitting and receiving 
inputs and outputs in batch or interactive mode. 


content: This Data Item Description (DID) contains the format 
and content preparation instructions. 


This DID is an alternative to Consolidated Software 
User/Operator Manual and Completely Consolidated 
Scftware Development Record). Only one of these three 
DIDs should be applied to a given set of data. 


Paragraphs that have been tailored out of the DID shall 
result in the corresponding paragraph number and title 
in the document, followed by "This paragraph has been 
tailored out." 


DOCUMENT STRUCTURE: 


ail Scope 
ive ee Loent fication 
1.2 System overview 
1.3 Document overview 
Zan Referenced documents 
he System description 
System application 
System organization 
Software inventory 
Information inventory 
324.22 Resource inventory 
334..2 Report inventory 
Processing overview 
Communications overview 
Security, privacy, and continuity of 
rations 
cription of runs 
Run inventory 
Phasing 
Diagnostic procedures 
Error messages 
4.x Run description for (run name or 
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Scope. This section shall be divided into the 
following paragraphs. 


Identification. This paragraph shall contain a full 
identification of the system and the CSCIs to which 
this document applies, including, as applicable, 
identification number(s), title(s), abbreviation(s), 
version number(s), and release number(s). 


System overview. This paragraph shall briefly state 
the purpose of the system and the software to which 
this document applies. It shall describe the general 
nature of the system and software; summarize the 
history of system development, operation, and 
maintenance; identify the project sponsor, user, 
developer, and support agencies; identify current and 
planned operating sites; and list other relevant 
documents. 


Document overview. This paragraph shall summarize _ the 
purpose and contents of this manual. 


Referenced documents. This section shall list by 
document number and title all documents referenced in 
this manual. This section shall also identify the 
source for all documents not available through normal 
Government stocking activities. 


System description. 


System application. This paragraph shall provide a 
brief description of the intended uses of the system. 


System organization. This paragraph shall describe the 
operation of the system by use of a chart showing the 
data processing operations, including how the different 
operations are interrelated. If sets of runs are 
grouped by time periods or cycles, then each set of 
integrated operations required on a daily, weekly, etc. 
basis shall be presented. If runs may be grouped 
logically by organizational level, the groups of runs 
that can be performed by each organizational level such 
as headquarters processing, field activity processing, 
etc., Shall be presented. 


Software inventory. This paragraph shall provide an 
inventory of the software that makes up the system. 
This listing shall include the software full name, 
software identification, as well as security and 
privacy considerations of the software and 
identification of the software necessary to continue or 
resume operation of the system in case of an emergency. 


Information inventory. 
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cise: ead Resource inventory. This paragraph shall list all 

permanent 
files and databases/data banks that are referenced, 
created, or updated by the system. This listing shall 
include, as applicable, file names, database/data bank 
names, file identifications, storage media, required 
storage (number of tapes or disks), and security and 
privacy considerations. The listing shall also 
identify those files and databases/data banks necessary 
to continue or resume operation of the system in case 
of an emergency. 


B24 .2 Report inventory. This paragraph shall list all 
reports produced 
by the system. This listing shall include the report 
name and identify the software that produces the 


TSpore: 
a5 Processing overview. This paragraph shall provide 


information applicable to the processing of the system. 
Subparagraphs may be used as needed to cover system 
restrictions, waivers of operational standards, 
information oriented toward specific support areas 
(e.g., library, small computer and teleprocessing 
support), or other aspects of processing such as 
interface with other systems. 


3.6 Communications overview. This paragraph shall contain 
a general description of the communications functions 
and processes of the system. This paragraph shall 
contain a chart of the communications network used in 
the system. 


2.7 Security, privacy, and continuity of operations. This 
paragraph shall contain an overview of the security and 


privacy consider-ations associated with the system, and 
the actions necessary to continue or resume operation 
in case of an emergency. 


4. Description of runs. This section shall provide a 
description of the runs to be performed, for use by 
operations and scheduling personnel in efficient 
scheduling of operations, assignment of equipment, 
management of input and output data, and restart/ 
recovery procedures. In on-line systems some 
information about system operational control may be 
related to the capabilities of the operating system. 
Much of the necessary information may be included in 
graphic representations with additional information 
that is specifically oriented to the hardware and 
software set being used. 


4.1 Run inventory. This paragraph shall provide a list of 
the runs to be performed, showing the software and the 


4 


{ fevin 


Mat 


rigexe axsq’ ett 


Jen 
ti ie a 4f9 
™ a 
S75. Sh 
hs oe a Bet 


(‘ete7 tO 


wi i i 
it 7s ii 
i - . 
= DLE 
1 
' 4 ‘ 
o 
~ 
i a 
4 
i | 
; 
Lol 
é i] 
— 
. 
4 > 
i 
-* > 
| 
- , 1, We 
. 3.6 


oniwoda 


exngd aieb\voendadits be Bas 
yd hessdqu xO | 


.aidseoliqags ws 


at x ' 
+2 ,6o ‘a BS eS SI icabl” elt? , pa 
5 to aeqad fo tedaua) spazose 
. eaots or ehienos yosve 


ale Fe 


74 


AviRl; 


=f 64 


att? opodd yi lined. a 
— to sxymfines oF 
-yoarspiemw us Io. 


ald? .7odgtevgl Jsrogqed 
F Hesvbosg ¢€ 

tI°ai Msiave e139 ve 
E * riisn6eb: Bas emen 
.220gs% 
ry iViSNS. De ignenose 
ofilaqgs aobcaemrotnt 
youn 251 P47sqdve 
; ijoLisest 
io ma)tJemrtoin? 
BIC i , 68,8) 
~s ( Fs0qque 
y sneaI tsi) 
O  BaOL Ins iummo) 
‘*oG0eh iszverep é 
5 895RS902G bas 
fen nisjoo5 
lave sa7 
eying uvitausea 
Liste tf PSt6q 
7&* wLe VYoSs\ £3¢ 
& & : ins 8n3 
m te 9aso nt 
BGS 3 fot je bead 
sao 36 noe! Igtinaed 
ubedie 6ba6 Sig Lsarego 
exeqo to puitubarsg 
JuqRt 30- 3c eh ci 
isiybéoosq yrevooe'r 

? P4 


sure 
bESS S507 


fIsInBRSIGe% Dfigesp 


é 


hoeay pied 


Hgsipsieqd sii 
Dewy} 
‘ 


aera 


uote. sot Jame 
aad o2 Setsiax 
S549 Io iouM 


soisk: 2598. 4f Jagd 
Joa Giswjtoa 


i ihe AS 


ft oF 


oa? 
a? 


jobs that make up each run. It shall include a brief 
summary of the purpose of the run. This list shall 
relate to the runs that are included in the remainder 
of this section. 


4.2 Phasing. This paragraph shall provide a schedule of 
acceptable phasing of the system into a logical series 
of operations. A system run may be phased to permit 
manual or semiautomatic checking of intermediate 
results, to provide the user with intermediate results 
for other purposes, or to permit a logical break if 
higher priority jobs are submitted. An example of the 
Minimum division for most systems would be edit, file 
update, and report preparation. 


4.3 Diagnostic procedures. This paragraph shall furnish 
the setup and execution procedures for any software 
diagnostics. Included shall be procedures for 
validation and trouble shooting. All parameters (both 
input and output), codes, and range values for 
diagnostic software shall be explained. 


4.4 Error messages. This paragraphs shall list all error 
messages output by the system, along with the 
corresponding correction procedure for each message. 


ax Run description for (run name or Identifier). 
Paragraphs 4.5 through 4.n shall provide the detailed 


information needed to execute runs of the system. The 
information provided shall be organized in a manner 
most useful to the information processing centers and 
operations personnel that will perform the runs. 


Ze elk Control inputs. This paragraph shall provide a listing 
of the 
run-stream of job control statements needed to initiate 
the run. 
4.xX.2 Run management information. This paragraph shall 


present the 
information needed to manage the run including, for 
example, the following information: 


a Run identification 

be Peripheral and resource requirements 

Gk Security and privacy considerations 

d Method of initiation, such as on request, as a 


another run, at a predetermined time, etc. 
e. Estimated run time 
ca Required turnaround time 
rep Messages and responses 
Fiz Procedures for taking check points 
ts Waivers from operational standards 
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sb. Contacts for problems experienced with the run 


Input-output files. This paragraph shall list 


information about 


4.x.4 
about the 


4.x.5 
provide 


EN ae ads 


the files and databases/data banks that serve as input 
to or that are created or updated by the run. Included 
for each shall be information such as name, security 
and privacy, recording medium, retention schedule, and 
disposition. 


Output reports. This paragraph shall list information 


reports that are produced during the run. Included for 
each report shall be information such as report 
identification, security and privacy, media (e.g., hard 
copy, electronic tape), volume of report, number of 
copies, and distribution of copies. 


Reproduced output reports. This paragraph shall 


information about computer-generated reports that are 
subsequently reproduced by other means. Included for 
each report shall be information such as report 
tGenti fication, security and privacy, reproduction 
technique, paper size, binding method, number of 
copies, and distribution of copies. 


Procedures for restart/recovery and continuity of 


operations. 


This paragraph shall provide procedures to be followed 
by information processing center personnel concerning 
restart/recovery in the event of a system failure and 
continuity of operations in the event of emergencies. 


Notes. This section shall contain any general 
information that aids in understanding this document 
(e.g., background information, glossary). This section 
shall include an alphabetical listing of all acronyms, 
abbreviations, and their meanings as used in this 
document and a list of terms and definitions needed to 
understand this document. 


Appendixes. Appendixes may be used to provide 
information published separately for convenience in 
document maintenance (e.g., charts, classified data). 
As applicable, each appendix shall be referenced in the 
main body of the document where the data would normally 
have been provided. 
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DOCUMENT : 


PURPOSE: 


CONTENT : 


BLM 80035B 


OPERATIONAL CONCEPT DOCUMENT (OCD) 


The Operational Concept Document (OCD) describes a 
proposed system in terms of the user needs it will 
fulfill, its relationship to existing systems or 
procedures, and the ways it will be used. 


An OCD is used to obtain consensus among development, 
Support, and user agencies and contractors on the 
operational concept of a proposed system. Depending on 
its use, an OCD may focus on communicating the user’s 
needs to the developer or the developer’s ideas to the 
user and other interested parties. The term "system" 
may be interpreted to apply to a portion of a system. 


This Data Item Description (DID) contains the format 
and content preparation instructions. 


This DID is an alternative to Consolidated Software 
Requirements Document and Completely Consolidated 
Software Development Record. Only one of these three 
DIDs should be applied to a given set of data. 


Paragraphs that have been tailored out of the DID shall 
result in the corresponding paragraph number and title 
in the document, followed by "This paragraph has been 
taviored “out.” 


DOCUMENT STRUCTURE: 


ate Scope 
i eeLoentt fication 
1.2 System overview 
1.3 Document overview 
PR Referenced documents 
3s Current system or situation 
3.1 Background, objectives, and scope 
3.2 Operational policies and constraints 
3.3 Description of current system or situation 
3.4 Users or involved personnel 
-5 Support environment 
ustification for and nature of changes 
.1 Justification for change 
.2 Description of needed changes 
.3 Priorities among the changes 
.4 Changes considered but not included 
5 Assumptions and constraints 
oncept for a new or modified system 
1 Background, objectives, and scope 
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5.2 Operational policies and constraints 
aia 

5.4 Users/affected personnel 

5.5 Support environment 

Operational scenarios 

Summary of impacts 

7.1 Operational impacts 

7.2 Organizational impacts 

7.3 Impacts during development 

Analysis of the proposed system. 

8.1 Summary of improvements 

8.2 Disadvantages and limitations 

8.3 Alternatives and trade-offs considered 
Notes 

Appendixes 


Description of the new or modified system 
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Scope. This section shall be divided into the 
following paragraphs. 


Identification. This paragraph shall contain a full 
identification of the system to which this document 
applies, including, as applicable, identification 
number(s), title(s), abbreviation(s), version 
number(s), and release number(s). 


System overview. This paragraph shall briefly state 
the purpose of the system to which this document 
applies. It shall describe the general nature of the 
system; summarize the history of system development, 
operation, and maintenance; identify the project 
sponsor, user, developer, and support agencies; 
identify current and planned operating sites; and list 
other relevant documents. 


Document overview. This paragraph shall summarize the 
purpose and contents of this document. 


Referenced documents. This section shall list by 
document number and title all documents referenced in 
this document. This section shall also identify the 
source for all documents not available through normal 
Government stocking activities. 


Current system or situation. This section shall be 
divided into the following paragraphs to describe the 
system or situation as it currently exists. 


Background, objectives, and scope. This paragraph 
shall describe the background, mission or objectives, 
and scope of the current system or situation. 


Operational policies and constraints. This paragraph 
shall describe any operational policies and constraints 


that apply to the current system or situation. 


Description of current system or Situation. This 
paragraph shall provide a description of the current 
system or situation, identifying differences associated 
with different states or modes of operation (for 
example, regular, maintenance, training, degraded, 
emergency, alternative-site). The description shall 
include, as applicable: 


a. The operational environment and its 
characteristics 

br Major hardware, software, and manual system 

components, 


including databases, and the interconnections 
among these components 


i a 
panon I[lesete aigateeyva@ @hif  iiossenta tana 


in tiv o3 
| =. | 
iiitol ~«SLOAO 


= ; | oe 


sh ist inti fs: ad tésde not s99e aint 


sive vdds tal stoig , (2) r9dmur 
«scart geeelex San ,(s)sedmya: 


6 benders prisulont 


i > : —s 
es 
ore Ww : 


i 
q 


alqespereg Bas 


+ 


meses eds to noljs>ktiyasbl 
{oq6 as ,gnibufont!  ,eetiegs ~ 


‘sieq ele?  .weivievo meyews 
; m@Jeaye sid 26 esoqrug,. sds 
odtrpeseb Liste 9I .seiiggs 

4i(f #3 SS iseniwe <metzave 

: jctem Bua yooltistede 
16jolsveh  .tseay .x.oOsedegs 
>igG fis Ihe tIwS Yalsnebs 
iamuyooD JIRSevelesr 3asIG 


we lVjevy Jfemunoed 
S71 ? BC 


lj 1GSmsnon 
C7701 iy) Bibs 
O2 eotzioe 
 Lamrrevogd 


m a ‘vy . 
_ = El a £e(. a Lidid 
- te. * : 
bsp vib 
4 1 Se cseva i 
’ al fr; ‘*) Lie . 5. 


<A iy 14406 Ngsxyes te 
iia TO meae “6 
ime 39 *izrb onsiw 


EQS RIS .T6ipes .sigmexs 
a (JacseJ[6 ,youspyams 
: IBD L. iG@& 86 sebirlods : 


1a [Rtotjaszeqa ait & 
Sole t2es ered 


[Sawa 2CE nfl | swEre esi a0 (aM * a 
‘0 ,@daenegmnos rm 


BIhenogmes 28en) coon 
. —— | 


-— | - 


_ 


ae 


7 4 a - a wv 


4.1 


ahs Interfaces to external systems or procedures 


dx Capabilities/functions of the current system 
e. Charts and accompanying descriptions depicting 
inputs, 


outputs, data flow, and manual and automated 
processes sufficient to understand the current 
system or situation from the user’s point of view 


tr Performance characteristics, such as speed, 
throughput, 
volume, frequency 
ae Quality attributes, such as reliability, 
maintainability, 
availability, flexibility, portability, usability, 
efficiency 
she Provisions for safety, security, privacy, and. 


Continuity, of 
operations in emergencies 


Users or involved personnel. This paragraph shall 
describe the types of users of the system, or personnel 
involved in the current situation, including, as 
applicable, organizational structures, training/skills, 
responsibilities, activities, and interactions with one 
another. 


Support environment. This paragraph shall describe the 
support concept and environment for the current system, 
including, as applicable to this document, support 
agency(ies); facilities; equipment; support software; 
repair/replacement criteria; maintenance levels and 
cycles; and storage, distribution, and supply methods. 


Justification for and nature of changes. This section 
shall be divided into the following paragraphs. 


Justification for change. This paragraph shall: 


a. Describe new or modified aspects of user needs, 
missions, 
objectives, environments, interfaces, personnel or 
other factors that require a new or modified 
system 


by Summarize deficiencies or limitations in the 
current system 
or situation that make it unable to respond to 
these factors 
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Description of needed changes. This paragraph shall 
summarize new or modified capabilities/functions, 
processes, interfaces, or other changes needed to 
respond to the factors identified in 4.1. 

Priorities among the changes. This paragraph shall 
identify priorities among the needed changes. It 
shall, for example, identify each change as essential, 
desirable, or optional, and prioritize the desirable 
and optional changes. 


Changes considered but not included. This paragraph 
shall identify changes considered but not included in 
4.2, and rationale for not including them. 


Assumptions and constraints. This paragraph shall 
identify any assumptions and constraints applicable to 
the changes identified in this section. 


Concept for a new or modified system. This section 
shall be divided into the following paragraphs to, 


describe a new or modified system. 


Background, objectives, and scope. This paragraph 
shall describe the background, mission or objectives, 


and scope of the new or modified system. 


Operational policies and constraints. This paragraph 
shall describe any operational policies and constraints 


that apply to the new or modified system. 


Description of the new or modified system. This 
paragraph shall provide a description of the new or 


modified system, identifying differences associated 
with different states or modes of operation (for 
example, regular, maintenance, training, degraded, 
emergency, alternative-site, wartime, peacetime). The 
description shall include, as applicable: 


aa The operational environment and its 
characteristics 

low: Major hardware, software, and manual system 

components, 


including databases, and the interconnections 
among these components 


Cr Interfaces to external systems or procedures 

ro oe Capabilities/functions of the new or modified 

system 

e. Charts and accompanying descriptions depicting 
inputs, 


outputs, data flow, and manual and automated 
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processes sufficient to understand the new or 
modified system or situation from the user’s point 


of view 
Ee Performance characteristics, such as speed, 
throughput, 
volume, frequency 
oe Quality attributes, such as reliability, 
maintainability, 
avarlabtidaty,sflexibility, portability, usability, 
efficiency 
hy Provisions for safety, security, privacy, and 


continuity of 
operations in emergencies 


Users/affected personnel. This paragraph shall 
describe the types of users of the new or modified 
system, including, as applicable, organizational 
structures, training/skills, responsibilities, and 
interactions with one another. 


Support environment. This paragraph shall describe the 
support concept and environment for the new or modified 
system, including, as applicable, support agency (ies) ; 
facilities; equipment; support software; 
repair/replacement criteria; maintenance levels and 
cycles; and storage, distribution, and supply methods. 


Operational scenarios. This section shall describe one 
or more operational scenarios that illustrate the role 
of the new or modified system, its interaction with 
users, its interface to other systems, and all states 
or modes identified for the system. The scenarios 
ghall include events, actions, stimuli, inform-ation, 
interactions, etc., as applicable. Reference may be 
made to other media, such as videos, to provide part or 
allmofsthiseinformation: 


Summary of impacts. This section shall be divided into 
the following paragraphs. 


Operational impacts. This paragraph shall describe 
anticipated operational impacts on the user, 
development, and support/ maintenance agency (ies). 
These impacts may include changes in interfaces with 
computer operating centers; change in procedures; use 
of new data sources; changes in quantity, type, and 
timing of data to be input to the system; changes in 
data retention requirements; and new modes of operation 
based on peacetime, alert, wartime, emergency, 
disaster, or accident conditions. 
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Organizational impacts. This paragraph shall describe 
anticipated organizational impacts on the user, 
development, and support/maintenance agency (ies). 
These impacts may include modification of 
responsibilities; addition or elimination of 
responsibilities or positions; need for training or 
retraining; and changes in number, skill levels, 
position identifiers, or location of personnel in 
various modes of operation. 


Impacts during development. This paragraph shall 
describe anticipated impacts on the user, development, 


and support/ maintenance agency(ies) during the 
development effort. These impacts may include 
meetings/discussions regarding new system; development 
or modification of databases; training; parallel 
operation of the new and existing systems; impacts 
during testing of the new system; and other activities 
needed to aid or monitor development. 


Analysis of the proposed system. 


Summary of improvements. This paragraph shall provide 
a qualitative and quantitative summary of the benefits 
to be obtained from the new or modified system. This 
summary shall include new capabilities, enhanced 
capabilities, and improved performance, as applicable, 
and their relationship to deficiencies identified in 
4.1. 


Disadvantages and limitations. This paragraph shall 
provide a qualitative and quantitative summary of 
disadvantages or limitations of the new or modified 
system. These disadvantages and limitations shall 
include, as applicable, degraded or missing 
capabilities, degraded or less-than-desired 
performance, greater-than-desired use of processing 
resources, undesirable operational impacts, conflicts 
with user assumptions, and other constraints. 


Alternatives and trade-offs considered. This paragraph 
shall identify and describe major alternatives 
considered to the system or its characteristics, the 
trade-offs among them, and rationale for the decisions 
reached. 


Notes. This section shall contain any general 
information that aids in understanding this document. 
This section shall include an alphabetical listing of 
all acronyms, abbreviations, and their meanings as used 
in this document and a list of any terms and 
definitions needed to understand this document. 
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Appendixes. Appendixes may be used to provide 
information published separately for convenience in 
document maintenance (e.g., charts, classified data). 
As applicable, each appendix shall be referenced in the 
main body of the document where the data would normally 
have been provided. 
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DOCUMENT : 


PURPOSE: 


CONTENTS : 


BLM 80036B 
SOFTWARE INPUT/OUTPUT MANUAL (SIOM) 


The Software Input/Output Manual (SIOM) tells a user 
how to submit queries and other inputs to a batch or 
interactive software system that is run by computer 

center staff, and describes the outputs that can be 

expected from the system. 


A SIOM is developed for software systems that run ina 
computer center and are accessed via terminals or batch 
inputs. It is an alternative to the Software User 
Manual (SUM), which tells hands-on users how to operate 
and use a software system without the aid of computer 
center personnel. 


This Data Item Description (DID) contains the format 
and content preparation instructions. 


This DID is an alternative to Consolidated Software 
User/Operator Manual and Completely Consolidated 
Software Development Record. Only one of these three 
DIDs should be applied to a given set of data. 


Paragraphs that have been tailored out of the DID shall 
result in the corresponding paragraph number and title 
in the document, followed by "This paragraph has been 
tailored out." For data delivered in an alternative 
form, this representation need occur only in the table 
of contents or equivalent. 


DOCUMENT STRUCTURE: 


aks Scope. 
ite Loentitication. 
1.2 System overview. 
1.3 Document overview. 
1.4 Security and privacy 
es Referenced documents 
oe System summary 
System description 
System operation 
System configuration 
System organization 
System performance 
Contingencies/alternate modes of operation 
Database/data bank 
ctions related to technical operations 
Initiation procedures 
Description of inputs 
Aan Inputeconditions 
oa Input formats 
3 Composition rules 
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Notes 


Input vocabulary 
Sample inputs 
iption of outputs 
General description 
Output formats 
Sample outputs 
Output vocabulary 
Use of system outputs 
Recovery and error correction procedures 
Communications diagnostics 
query procedures 
System query capabilities 
Database/data bank format 
Query preparation 
Control instructions 
terminal processing procedures 
Available capabilities 
Access procedures 
Display, updates, and retrieval procedures 
Recovery and error correction procedures . 
Termination procedures 
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Scope. This section shall be divided into the 
following paragraphs. 


Identification. This paragraph shall contain a full 
identification of the system and the CSCIs to which 
this document applies, including, as applicable, 
identification number(s), title(s), abbreviation(s), 
version number(s), and release number(s). 


System overview. This paragraph shall briefly state 
the purpose of the system and the software to which 
this document applies. It shall describe the general 
nature of the system and software; summarize the 
history of system development, operation, and 
Maintenance; identify the project sponsor, user, 
developer, and support agencies; identify current and 
planned operating sites; and list other relevant 
documents. 


Document overview. This paragraph shall summarize the 
purpose and contents of this manual. 


Security and privacy. This paragraph shall contain an 
overview and discussion of the security and privacy 
considerations associated with the system. A warning 
shall be included regarding making unauthorized copies 
of data, software, or documents if applicable. 


Referenced documents. This section shall list by 
document number and title all documents referenced in 
this manual. This section shall also identify the 
source for all documents not available through normal 
Government stocking activities. 


System summary. This section shall provide a general 
overview of the system written in nontechnical 
terminology. Detailed technical information shall be 
presented in other sections. 


System description. This paragraph shall explain in 
general terms the uses for which the system is 
intended. Capabilities, operating improvements, and 
benefits expected from its use shall be described. The 
description shall include major functions performed by 
the system, such as generation of output, maintenance 
of data, and display of information. This description, 
part of which may be displayed graphically, shall show: 


a. Logical parts of the system from the point of 
view of 
the user. 
be Communication paths and techniques. 
or Interfaces and relationships to other 


systems. 
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a3 The organizations that provide input to the 
system or 
that receive output from it. 


System Operation. This paragraph shall show the 
relationships of the functions performed by the system 
with the organizations or stations that are sources of 
input to the system and those that are recipients of 
outputs from it. Included shall be charts and a brief 
narrative description including only the who, what, 
where, and why concerning the inputs and outputs on the 
chart < 


System Configuration. This paragraph shall briefly 
describe the equipment, communications, and networks 
used by the system. It shall include the type of 
computer and input and output devices. 


System Organization. This paragraph shall present a 
general overview of the organization of the system... 
The presentation shall show, as appropriate, the 
logical parts of the system and a brief description of 
their roles in the operation of the system. 

System Performance. This paragraph shall describe the 
overall performance characteristics that can be 
expected by the user. Constraints, such as capacity 
limitations or time needed to accomplish major 
functions, shall be included. Performance measures and 
information of interest are represented by the 
following examples: 


a. Input - types, volumes, rate of inputs accepted 
|o 5. Output - types, volume, accuracy, rate of outputs 
that the 


system can produce 


e. Response - time factors that affect response 
time, such as 
type and volume of input and equipment 


configurations 
ae Limitations - maximum size per unit of input, 
format 


constraints, restrictions on what data may be 
queried and from what location, and language 


constraints. 
e. Error - rate capabilities for detecting various 
legal and 
logical errors and the means provided for error 
correction. 


ee Processing time - typical processing times. 
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a. Flexibility - provisions allowing extension of the 
usage of 
the system. 


He Reliability - system provisions that support, for 
example, 
alternate processing or a switch over capability. 


Contingencies/alternate modes of operation. This 
paragraph shall explain the general nature of the 


differences expected in what the user will be able to 
do with the system at times of emergencies, disasters, 
and accidents that may preclude normal system 
operation. The paragraph shall also explain any 
differences in what the user will be able to do based 
on modes of operation that differ between peacetime, 
war), and, CcondstaonsFrornalert: 


Database/data bank. This paragraph shall describe the 
method used to store and maintain the data. 
a. For systems using a Database Management System 
(DBMS) , 
this paragraph shall provide information on the 
particular DBMS used including the types and usage 
of the data. 


b For systems using a data bank, this paragraph 
shall 
identify all files that make up the system. This 
list shall contain at least the file 
identification, retention, media, and sensitivity. 


General description of inputs, processing, outputs. 
This paragraph shall describe the inputs, the flow of 


data through the processing cycle, and the resulting 
outputs. 


a. Inputs. The description of inputs shall include 
the 
following, as applicable: 


Dy) Purpose of the input; conditions or events 


its submission 
2) Content of input in terms of operational, 


OF 


reference data 
3) Other inputs required by the system in 


direct input 
4) Source or preparer of the input 
5) Database/data bank where the input is 


recorded in 


general or functional terms 
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6) Security and privacy considerations 


7) Additional remarks of general information 
De Processing. The description of processing shall 
include 
the relationship of the input to the output with a 
general description of the flow of data through 
the processing cycle. 
ey Outputs. The description of outputs shall 
include the 


following, as applicable: 


1) List of outputs produced by the system 


showing their 


that 


informatio 


4.2 


2) Net aaah 
conditions 


relationship to the inputs 
2 Purpose of the output; conditions or events 


require its generation 


3) General description of information provided 
by the 
output 
4) Other system outputs that complement the 
neon 
the output 
5) Recipients of the output 
6) Security and privacy considerations 
7) Additional items of general information 


Functions related to technical operations. This 
section shall provide the details necessary to prepare 
inputs to the system. The logical arrangement of the 
information shall enable the functional personnel to 
prepare required inputs. In addition, this section 
shall explain in detail the characteristics and meaning 
of the information the system produces as outputs. If 
an on-line system with batch processing capabilities is 
being described, this paragraph shall reference 
Sections 6 through n to describe the terminal 
operations; and the following paragraphs shall detail 
the procedures to be followed for the batch processing 
runs. 


Initiation procedures. This paragraph shall detail the 
procedures that must be followed to initiate system 
operation. Included may be information such as sample 
job request forms or sample control statements. LE 
these procedures are standard or are detailed in 
another manual, that manual shall be referenced. 


Description of inputs. 


Input conditions. This paragraph shall delineate the 
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y to be observed in preparing each type or class of input 
a to the system. The conditions shall include the 
’ following, as applicable: 


a. Reason for input - note the operational conditions 
that 
require the submission of the input, e.g., 
catastrophe, normal status report, need to enter 
parameters, need to update data, the desire to 
Optainsparticular data; “the need'to respond to a 
particular display 
Ds Frequency of input - specify when the input must 
be 
prepared, e.g., periodically, randomly as a 
function of an operational situation 
Ge Origin of input - identify the organizational unit 
or 
Station authorized to generate the input 
ag Medium of input - note the medium used to enter 
the input 
e. Associated inputs - reference any related inputs 
bhap.are 
required to be entered at the same time as this 
input 
£ Other - note any other applicable information, 


such as other 
recipients of the inputs; DoIOmity; iSecurily. and 
privacy considerations; variations on the basic 
input format using code or key indicators; 
limitations on what files may be affected by a 
particular type of input 


Ben. 2 Input formats. This paragraph shatledllustratetthe 
layout 
formats to be used in the initial preparation of system 
inputs and shall explain the information that may be 
entered in the various sections and lines of each 
format. The explanation of each entry provision shall 
be keyed to the sample formats shown. 


NP Composition rules. This paragraph shall describe any 
rules and 
conventions that must be observed to prepare sajerthe, jelgthe 
can be accepted by the system. The rules of syntax, 
usage of punctuation, etc. shall be explained. The 
rules shall include the following, as applicable: 


2 a. Input transaction length - e.g., 100,characcters 
7 maximum 


® 


4.2.4 
legal 


a2 45 
that 


hy Format conventions - e.g., all input items must be 
left- 
justified 
C. Labeling - e.g., usage of identifiers to denote 
major data 
sets to the system 


de Sequencing - e.g., the order and placement of 
items in the 
input 
e. Punctuation - e.g., spacing and use of symbols 
(virgule, 


asterisk, character combinations, etc.) to denote 
Start and end of input, of data groups, and of 
fields 
ie Restrictions - e.g., rules forbidding use of 
particular 
characters or parameter sets 


Input vocabulary. This paragraph shall explain the 


character combinations or codes that must be used to 
identify or compose input items. An appendix may be 
provided containing an ordered listing of item codes 
that can be entered into an input to the system. 


Sample inputs. This paragraph shall provide examples 


illustrate and explain each type or class of input 
acceptable by the system. Included in the explanation 
shall be information on the following types of inputs, 
as applicable: 


a. Header - containing entries that denote the input 
type or 
class, date and time, origin, instruction codes to 

the system, etc. 


| ey Text - containing the portions of the input 
representing 
data for operating files, request parameters for 
information retrieval, etc. 


Cy Trailer - containing control data denoting the end 
Sleanput 
and any additional control data 


rele, Omission - indicating those types of input that 
may be 
omitted at the option of the composer or because 
of particular circumstances concerning the input 


e. Repeats - indicating those portions of the input 
that may be 
repeated up to a specified maximum number of 
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entries, if required 


AS Description of outputs. 
7 ec eal General description. This paragraph shall provide the 
following 


information for each type or class of output: 


a. Purpose - the reasons why the output is generated 
b. Frequency - whether the output is produced 
periodically or 
as required. If produced periodically, the period 
must be specified 


CG. Options - any modifications or variations of the 
basic 
output that are available 
as Media - physical form of the output, such as 
Drincout, 
display screen, tape 
e. Location - where the output will appear, such as 
tHiathe 


computer area or remotely at a particular physical 
area or station 
. Other - any additional characteristics of this 
eutput, such 
as priority, security and privacy considerations, 
associated outputs that complement the information 
in this output 


4°32 Output formats. This paragraph shall illustrate and 
explain the 
layout of each type or class of system output. 
Explanations shall be keyed to particular parts of the 
format illustrated. The following information shall 
be provided, as applicable: 


a. Security and privacy marking 
be Header - the title, identification, date and time 
of day, 


number of output parts, and similar basicecontrol 
data that may be contained in the header or 
control segment of the output 


Se Body - the information that may appear in the body 
or text 

OF ehesoutput; “theesignificance oft fixed data, 
such as columnar headings in tabular display types 
of output; the existence of subsets or sections in 
the output format (e.g., part A, part B) ; any 
fixed positions or column locations allocated to 
specific output information 


ar Trailer - the control or reference information 
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that may be ; 
e appended to the body of information presented 


e. Additional characteristics concerning the makeup 
of outputs 
such as the meaning of special symbols, etc. 


| ge Re Sample outputs. This paragraph shall provide 
illustrations of 
each type or class of output available from the system. 
The function or purpose of each output shall be 
explained. A detailed description shall be provided, 
including the following information, as applicable: 


a. Definition - the meaning and use of each 
information 
variable for the reader or user 


be Source - was the item extracted from a specific 
Enput;, from 
a database/data bank file, calculated by system, 

etc. 


eG. Characteristics - for example, omission of the 
item under 
certain conditions of the output generation, range 
of values, unit of measure 


4.3.4 Output vocabulary. This paragraph shall describe any 


abbreviations that appear in the output in a form 
different from those used on the input described in 
paragraph 4.2.4. 


4.4 Use of system outputs. This paragraph shall explain 
the use of the output by the operational area or 
activity that receives it. For example, a summary 
report of petroleum, oil, and lubricant stocks may be 
received by a material control activity and, depending 
on the information in the report, action might be 
required to initiate the purchase or transfer of stocks 
to a particular location. 


4.5 Recovery and error correction procedures. This 
paragraph shall list the error codes generated by the 
software, give their meanings, and describe the 
corrective actions to be taken by the user. Also 
included shall be the procedures to be followed by the 
user with respect to restart, recovery, and Cont nuLey 
of operations in the event of emergencies. 


describe in detail the diagnostic procedures available 


» 4.6 Communications diagnostics. This paragraph shall 
3 to the user of the system for validating communications 
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and for identifying and classifying problems. 


File query procedures. This section shall be prepared 
for a system with a file query retrieval capability 
that does not use terminals. The instructions 
necessary for recognition, preparation, and processing 
of a query applicable to the database/data bank shall 
be explained in detail. 


System-query capabilities. This paragraph shall 
illustrate in tabular form the preprogrammed query 


capabilities provided by the system with a description 
of, or a cross-reference to, a query code. 


Database/data bank format. This paragraph shall 
illustrate the database/data bank format and content. 
An example is shown in Figure 2. For each data 
element, information such as the following shall be 
listed, as applicable: 


Data element name 

Synonymous names 

Definition 

Format 

Range and enumeration of values 

Unit of measurement 

, Data item names, abbreviations, and codes 


@moaandw® 


When the information is published in a data element 
dictionary, reference to an entry in the dictionary 
shall be made rather than including an extract from 
that dictionary. Any variations in either the inputs 
or outputs from the format or data items that are used 
on the database/data bank shall be specifically 
identified. 


Query preparation. This paragraph shall provide 
instructions for the preparation of any necessary query 


parameters. The details of query input preparation in 
the context of each specific database/data bank and 
system retrieval capability shall be repeated as 
necessary in the form of positive instructions. In 
cases when the retrieval capability is part of a 
support system and query input formats are not needed, 
the specific query statement required shall be listed. 
The formats provided shall be usable to transcribe 
queries into technical phrasing of the retrieval 
system. Subparagraphs shall be used to describe 
different types of queries. 


Control instructions. This paragraph shall provide 
instructions for the sequencing of runs and for the 
software necessary to extract responses to query 
requests from the database/data bank. These 
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update 


instructions shall include the requirements for, and 
the preparation of, control statements that may be 
required by the computer system or software. If 
extensive information regarding control statement 
preparation is contained in support system 
documentation, this documentation may be referenced. 


User terminal processing procedures. This section 
shall provide the user with technical information on 
the use of terminals to accomplish processing. If 
procedures are complicated or extensive, Sections 7 
through n may be added in the same paragraph structure 
as this section. The organization of the document will 
depend on the characteristics of the system being 
documented. For example, if the tasks of users vary 
depending upon the organizational echelon in which they 
work, Section 6 might be oriented to headquarters 
functions and Section 7 to remote site functions. For 
another system, it may be more appropriate to have 
Section 6 be a guide to menus used in the system, 
Section 7 be a guide to command language used in the 
system, and Section 8 be a guide to functions. 

Detailed procedures are intended to be presented in 
paragraphs 6.2 through 6.5. Depending on the design of 
the system, the subparagraphs might be organized on a 
function-by-function basis or on a menu-by-menu basis. 
For a transaction-oriented system the organization 
might be on a screen-by-screen basis. 


Available capabilities. This paragraph shall describe 
in general terms capabilities for retrieval, display, 
and update of data through terminal operations. This 
description shall include estimates of the frequency of 
these operations and identification of the events that 
caused them to be initiated. 


Access procedures. This paragraph shall present the 
sequence of steps required to initiate system 
operations and to access the database/data bank. 
Included shall be such information as the name of the 
system or subsystem being called and other control 
information such as: 


a. The offices or personnel authorized to retrieve or 
De Time periods when such access is 
allowed 
Cr Information for ensuring that only authorized 
access is 
allowed 
Display, updates, and retrieval procedures. This 


paragraph shall be divided into subparagraphs to 
describe the step-by-step procedures necessary to 
produce the various displays, updates, and retrievals 
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that are available through the use of a terminal. For 
each procedure, information such as the name of the 
operation, input formats, and sample responses may be 
included. 


Recovery and error correction procedures. This 
paragraph shall provide error codes and messages that 


may be displayed by the system and indicate their 
meanings and any corrective actions that should be 
taken.. Also included shall be any procedures to be 
followed by the user with respect to restart, recovery, 
and continuity of operations in the event of 
emergencies. 


Termination procedures. This paragraph shall present 
the sequence of steps necessary to terminate the 
processing. 


Notes. This section shall contain any general 
information that aids in understanding this document. 
(e.g., background information, glossary). This section 
shall include an alphabetical listing of all acronyms, 
abbreviations, and their meanings as used in this 
document and a list of terms and definitions needed to 
understand this document. If section 6 has been 
expanded into section(s) 7,...n, this section shall be 
numbered as the next section following section n. 


Appendixes. Appendixes may be used to provide 
information published separately for convenience in 
document maintenance (e.g., charts, classified data). 
As applicable, each appendix shall be referenced in the 
main body of the document where the data would normally 
have been provided. 


gotubanoiy, solos 


i 


io seu 2a2> Pe , ekelaekaan 
‘1 es dows folgaenrotme (eiube 
> sfcee bra . Geez? dirk) .oe 


_— ~~ 


; 
3 REebOD torr: sores wen Aqeypexea 
ic’ San mgeye saa yd beyselqats ed yea 
EQuigSS svivesxzop yas base eonlgesn 
50d {fledes bebuigaioos LA Gare? 


> ‘ecres’: titiw wei no YG bewol Lo? 


1° anottsisqs Jo yatimiigues bas 
49 [20 P7TaMnsS 


. 2IUbe5030 posse gr Saes 
J a2cve8n e@eya 3 Sonsiupess oa 
piriaespcig 


= 


DOCUMENT: BLM 80534B 


SYSTEM/SEGMENT DESIGN 
DOCUMENT (SSDD) 


1 _ 
| " 
*. 7 . 
i) ee OAL 
: : 
a 


qNee02 MIS <THAMUDO 


240 TAIMOTeMaATEYS- 
ade2) TASMUIOG 


DOCUMENT : 
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PURPOSE: 


CONTENT : 


BLM 80534B 


SYSTEM/SEGMENT DESIGN DOCUMENT (SSDD) 


The System/Segment Design Document (SSDD) describes the 
organization of a system or segment into Hardware Configuration 
Items (HWCIs), Computer Software Configuration Items(s), and 
manual operations and describes the allocation of system 
requirements to the HWCIs, CSCIs, and manual operations. The 
term "system" in this DID may be interpreted to mean "Segment" as 
applicable. 


The SSDD describes the system/segment design and is used as the 
basis for developing requirement specifications for the HWCIs and 
CSCIs and interface specifications for the interfaces internal 
and external to the system. 


This Data Item Description (DID) contains the format and content 
preparation instructions. 


This DID is an alternative to Consolidated Software Design 
Document and Completely Consolidated Software Development Record. 
Only one of these three DIDs should be applied to a given set of 
data. 


Paragraphs that have been tailored out of the DID shall result in 
the corresponding paragraph number and title in the document, 
followed by "This paragraph has been tawlored out.) ~Por data 
delivered in an alternative form, this representation need occur 
only in the table of contents or equivalent. 
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Scope. This section shall be divided into the following 
paragraphs. | 


Identification. This paragraph shall contain a full 
identification of the system to which this document applies, 
including, as applicable, identification number(s), title(s), 
abbreviation(s), version number(s), and release number(s). 


System overview. This paragraph shall briefly state the purpose 
of the system to which this document applies. It shall describe 
the general nature of the system; summarize the history of system 
development, operation, and maintenance; identify the project 
sponsor, user, developer, and support agencies; identify current 
and planned operating sites; and list other relevant documents. 


Document overview. This paragraph shall summarize the purpose 
and contents of this document. 


Referenced documents. This section shall list by document number 
and title all documents referenced in this document. This 
section shall also identify the source for all documents not 
available through normal Government stocking activities. 


System/segment behavioral design. This section shall be divided 
into paragraphs as needed to describe design decisions that 
transcend the internal structure of the system. Examples may 
4nclude decisions about: how the system will appear to the user, 
how the system will behave, appearance of displays/reports, 
meanings of console keys, and other choices for meeting the 
system requirements. If all such decisions are explicit in the 
requirements or are deferred to the design of the system 
components, this section may so state. Examples of information 
that may be presented here are the following: 


a. Decisions on allowed/expected inputs/operations, including 
source, media, volume, frequency, sequence, priority; 
timing, format, units of measure, range of values, 
abbreviations, and codes. 


De Decisions on planned behavior in response to each 
input/operation, including sequence, timing, selected 
equations/algorithms/rules, and handling of illegal inputs. 


Co Decisions on system displays, reports, etc., including 
formats, media, volume, frequency, priority, ELMIngs 
recipients, forms, security, privacy, units of measure, 
range of values, abbreviations, and codes. 


ae Decisions on system databases/data banks, including 
contents, size, records/entries, media; security) privacy, 
retention schedule, and names, synonyms, definitions, units, 
formats, range, abbreviations, and codes for the data 
elements. 
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e. Decisions on the type of flexibility and the levels of 
availability, integrity, and confidentiality to be offered 
by the system. 


System architecture. This section shall be divided into 
paragraphs as needed to describe the system architecture. A 
system architecture diagram may be used. This section shall: 


a. Describe the internal structure of the system, identifying 
the segments, HWCIs, and CSCIs and summarizing the purpose 
of each. 

br Describe the relationships among the segments, HWCIs, and 


CSCIs, including sequence of execution, as applicable. 


ois Identify, state the purpose, and provide a high-level 
description of each external interface of the system. 


Allocation of requirements. This section shall be divided into 
the following paragraphs to identify the system/segment 
requirements allocated to each HWCI, CSCI, and manual operation 
of the system. This section shall identify the HWCI(s) within 
the system that are to be designated as Prime Item(s) or Critical 
Item(s). 


HWCI identification. This paragraph shall be divided into 
subparagraphs to identify the system requirements allocated to 
each HWCI. 


(HWCI_ name and project-unique identifier). This paragraph shall 


identify a HWCI by name and project-unique identifier and shall 
state its purpose. This paragraph shall identify each system 
requirement allocated to the HWCI. 


CSCI identification. This paragraph shall be divided into 
subparagraphs to identify the system requirements allocated to 
each CSCI. 


(CSCI _ name and project-unique identifier). This paragraph shall 


identify a CSCI by name and project-unique identifier, and shall 
state its purpose. This paragraph shall identify each system 
requirement allocated to the CSCI. 


Manual operations. This paragraph shall be divided into 
subparagraphs to identify system requirements allocated to each 
manual operation. 


(Manual operation name and project-unique identifier). This 


paragraph shall identify a manual operation by name and project- 
unique identifier and shall state its purpose. This paragraph 
shall identify each system requirement allocated to the manual 
operation. 


Internal interfaces. This paragraph and shall be divided into 
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the following subparagraphs to identify the system requirements 
affecting each interfaces between configuration items in the 
system. This paragraph may reference a system internal interface 
diagram. 


(HWCI-to-HWCI_ interface name/identifier). This paragraph shall 
identify by name and project-unique identifier all HWCI-to-HWCI 
interfaces within the system and shall identify any system 
requirements affecting each interface. 


(HWCI-to-CSCI_ interface name/identifier). This paragraph shall 
identify by name and project-unique identifier all HWCI-to-CSCI 
interfaces within the system and shall identify any system 
requirements affecting each interface. 


(CSCI-to-CSCI_ interface name/identifier). This paragraph shall 
identify by name and project-unique identifier all CSCI-to-CSCI 
interfaces within the system and shall identify any system 
requirements affecting each interface. 


Processing resources. This section shall be divided into the 
following paragraphs to describe the processing resources to be 
used for the system. 


(Processing resource name/identifier). This paragraph shall 


identify a processing resource by name and project-unique 
identifier. This paragraph shall identify the configuration 
items that will use the resource. For each processing resource, 
this paragraph shall specify the hardware, programming, design, 
coding, and utilization characteristics of the processing 
resource. In addition, this paragraph shall define the following 
computer hardware characteristics of the processing resource, as 
applicable: 


ay Memory size: Amount of internal memory (absolute, spare, or 
both) of the computer 

De Word size: Number of bits in each computer word 

C Processing speed: Computer processor capacity (absolute, 


Spare, or both) (e.g., a twenty percent reserve when in the 
full operational configuration) 


d. Character set standard (e.g. ASCII, EBCDIC) 

e. Instruction set architecture 

te Interrupt capabilities 

G: Direct Memory Access (DMA) 

hs Channels and channel capacities (absolute, spare, or both) 

ine Auxiliary storage capacities (absolute, spare, or both) 

aes Growth capabilities of any part of the processing resource 

ke Diagnostic capabilities 

ee Any additional hardware capabilities (e.g., fault tolerance, 
preprocessing) 

m. Allocation of pertinent processing resources to each CSCI 


Requirements traceability. This section shall provide 
traceability from the system requirements to the HWCIs, CSCIs, 


eee 
‘tiznsth of adestositegdos pmara i oe tt 
3£102 nsewset seostrestat ise polinesae 


5 SDuSTS tor van Agstpeteg Brat esas 


teh Ligeeb he 8G. Susteedas LOWE od 
| suuineeasarota bos emad va Vilas 
iinve base phteee eae bets Eve aensixesat 
Sinz dose pristpstts sryaamexs VP 


Ve 


Ja ; SPUTGg Oris 3msit rc vi. Fete 
=: Oo weve off aldjiw escetveasaee 
3 ‘ foss r"oa7cs ern9no7Lupead 


fe Sho LS & £4, a 
. i 
mad vi vilgies 


S “4 iy i" ta) ey “y #5 47 
ts S2089ST Lopes 
Fr rr FS 
= 4 ai > Je ; ——s 
11U9GS2DSTeY po Lfoz 
RalJeVe Sn j : Oar 
25 EULESS 
t ci“ y é& U ; 
eS Le i 
Latr & F 
> Li} a4 
i i a fi 7 £ 
} 5) al pn Bt y 
LA > ©~Iicy 
' | s 
j : i r 
| L82950 
ue i o oa TL4 
arin J 
‘ : ~4 i 
>) lat: , 
‘ 
35 ie ; ; 
J LAC 44 oe e 
1) Wi (vi “1. 
oP a @ 
he az j ci AA? ol 
oy ? CETE \ 4 bi 
Bol J Las0e5 Wo Y 
OAS TLSEORp 
J 


9 


and manual operations of the system, to demonstrate that each 
system requirement has been allocated. The traceability may be 
shown in a table. 


Notes. This section shall contain any general information that 
aids in understanding this document (e.g., background 
information, glossary, rationale). This section shall contain an 
alphabetical listing of all acronyms, abbreviations, and their 
meanings as used in this document and a list of any terms and 
definitions needed to understand this document. 


Appendixes. Appendixes may be used to provide information 
published separately for convenience in document maintenance 
(e.g., charts, classified data). As applicable, each appendix 
shall be referenced in the main body of the document where the 
data would normally have been provided. 
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PURPOSE: 


CONTENT: 


BLM 80022B 


FIRMWARE SUPPORT MANUAL (FSM) 


The Firmware Support Manual (FSM) provides the information 
necessary to load software or data into firmware components of a 
system. It applies to read only memory (ROMS), Programmable ROMs 
(PROMs), Erasable PROMs (EPROMs), and other firmware devices. 


The FSM describes the firmware devices and the support software, 
Support equipment, and procedures required to load software into 
firmware devices, to verify the load process, and to test the 
firmware device for proper functioning. 


This Data Item Description (DID) contains the format and content 
preparation instructions. 


This DID is an alternative to Consolidated Software Support 
Document and Completely Consolidated Software Development Record. 
Only one of these three DIDs should be applied to a given set of 
data. 


Paragraphs that have been tailored out of the DID shall result in 
the corresponding paragraph number and title in the document, 
followed by "This paragraph has been tailored out." For data 
delivered in an alternative form, this representation need occur 
only in the table of contents or equivalent. 


DOCUMENT STRUCTURE: 


be Scope 
isl g@adentification 
1.2 System overview 
1.3 Document overview 
a Referenced documents 
a. Firmware device information 
3.1 Device description 
3.2 Installation and repair procedures 


323 tSecursty andsprivacy 
3.4 Limitations 
4. Programming equipment and procedures 
4.1 Programming hardware 
4.2 Programming software 


4.3 Loading procedures 
Vendor information 
Notes 

. Appendixes 
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Scope. This section shall be divided into the following 
paragraphs. | 


Identification. This paragraph shall contain a full 
identification of the system and the CSCIs to which this document 
applies, including, as applicable, identification number(s), 
title(s), abbreviation(s), version number(s), and release 
number(s). This paragraph shall also identify by name and number 
all firmware components to which this FSM applies. 


System overview. This paragraph shall briefly state the purpose 
of the system and the software to which this document applies. 
It shall describe the general nature of the system and software; 
summarize the history of system development, operation, and 
Maintenance; identify the project sponsor, user, developer, and 
Support agencies; identify current and planned operating sites; 
and list other relevant documents. 


Document overview. This paragraph shall summarize the purpose 
and contents of this manual. 


Referenced documents. This section shall list by document number 
and title all documents referenced in this manual. This section 
shall also identify the source for all documents not available 
through normal Government stocking activities. 


Firmware device information. This section shall be divided into 
the following paragraphs to describe the firmware devices. This 
section may reference commercially available documents for the 
information required by the following paragraphs. 


Device description. This paragraph shall contain a complete 
physical description of the firmware components of the system. 
This paragraph shall provide the following for each device: 


a. Device name and manufacturer’s ID and number 

b Memory size and configuration (e.g., 64Kx1, 8Kx8) 

or Operating characteristics (e€.g., access time, power 
requirements, logic levels) 


d. Pin functional descriptions 

a Logical interfaces (e.g., addressing scheme, chip selection, 
etc.) 

a Internal and external ID scheme used with each device 

g. Timing diagrams 


Installation and repair procedures. This paragraph shall contain 
all installation, replacement, and repair procedures for the 


firmware devices. This paragraph shall also include remove-and- 
replace procedures, device addressing scheme and implementation, 
socket number for each device, description of the host board 
layout, and any procedures for ensuring continuity of operations 
in the event of emergencies. 
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Security and privacy. This paragraph shall describe any security 
and privacy measures to be applied to the devices and the 
Supporting hardware and software. 


Limitations. This paragraph shall describe the operational and 
environmental limits to which the devices may be subjected and 
Still maintain satisfactory operation. This data shall be 
provided for all firmware components of the system. 


Programming equipment and procedures. This section shall be 
divided into the following paragraphs to provide a description of 


the equipment, software, and procedures to be used for 
programming and reprogramming all firmware components of the 
system. This section may reference commercially available 
documents for the information required by the following 
paragraphs. 


Programming hardware. This paragraph shall describe the 
equipment to be used for programming and reprogramming each 
firmware device. It shall include computer peripherals, general 
purpose equipment, and special equipment used for device loading, 
burn-in, and test (including verification that the proper content 
is stored). Each piece of equipment shall be identified by 
manufacturer, manufacturer’s designation, and any other 
information that is necessary to uniquely identify that piece of 
equipment. A description of each piece of equipment shall be 
provided, including its purpose, usage, and major capabilities. 


Programming software. This paragraph shall describe the software 
to be used for programming and reprogramming each firmware 
device, including software for device loading, burn-in, and test. 
Utility programs to be used shall also be described. Each 
software item shall be identified by vendor, vendor’s 
designation, version, and any special features. A description of 
each software item shall be provided, including its purpose, 
usage, and major capabilities. 


Loading procedures. This paragraph shall describe the procedures 
to be used for programming and reprogramming each firmware 
device, including device loading, verification, and test. All 
equipment and software necessary for each procedure shall be 
identified. 


Vendor information. This section shall include information 
Supplied by the device vendor or shall reference the appropriate 
commercially available document(s). This section shall also 
include all commercially available information for support 
equipment and software or shall reference the commercially 
available document(s). 


Notes. This section shall contain any general information that 
aids in understanding this document (e.g., background 
information, glossary). This section shall include an 
alphabetical listing of all acronyms, abbreviations, and their 


& 


ein on oe ; 
. an 

7 oa _— a a 
(fare HQsIpsSIeg eit - VORBYV. a és st: 


rob wit of belfigqgs ed o9 avseacee F% oa q be 


sdiioesb Ifs 
“7 anDLVS) Si 


liacé nolgcee BlAY .tvreeee fp (aotss 
vestdds \mevaosos tis 10 patgeil isgttac 


eee 


.stewtice bas erewbtal oak 3: 


~~, 


a dosipetsq Bint —.g0¢ 
i foidw OF eithak! flesaer 

it nolisteqo yiodosselzee nissolam 
49 3o einsaeqhdo sxsworsk? Ife -y0t Bab 


BST OSoeT? Divs shame lupe pc bees eT 
ISIS iLAgd  polwoistor cial ome Oshi b 
aii PCG Ooms Siswiied., Jcemyigoe eis 

BW rs oni seOugs? ‘brie ba Linnea re 

Tet io lez.vyem aoliose gia’ siege 

= vers ‘ansosal ia xo? o2g¢om . 

- SIQGsICAXee 

a 

: ; SSW 2 BO Lae SOF 7 
a | Yo? S8eav 60 O27 J ramg t Ne 
be é 'z DiVeb- esyawart 


rs eers\ a] , 1a ; ips aE 
5 ced Dea tog ) 5oas. .nb- oe, 
‘ = * ss be . (beyose ek 
ase : TSIUVIDE ee 

. 1 of “er” nolseerro%ssE 

cae ; 7 ooMye Wps. 
M7 t “IES Bbobsvo 7g 


: ~ ’ eh Wii iT-rit, 
rf i ed oF" 
E | H ,oolveBb 
¢ i Lec VIL iLLIG 
" o7 wiitce 


e7 rvs nt HULS2i] soi vei 
iit ang tupe 
»be.tfsasas 

au or ave wes |i» nb ts Pa aobasy¥ 

v Soiveb edi yd besfaguva: 

munch sideiteve yCisiovennes: 

T fieve ‘prasewen iis abelos 
somero tex I Dei | S26wilew bos Jteomebupe 
. (a) Sasrupeb pcagrion. ~ 


us. yas alegneo lisde opttces elit (pede 
2-2) IJnetwoeh ate? paihassarsbay ak: ose 


re<¢e ¢\424 
® 


_ 


-s 


meanings as used in this document and a list of terms and 
definitions needed to understand this document. 


Appendixes. Appendixes may be used to provide information 
published separately for convenience in document maintenance 
(e.g., Charts, classified data). As applicable, each appendix 
shall be referenced in the main body of the document where the 
data would normally have been provided. 
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DOCUMENT: BLM 80018B 
COMPUTER SYSTEM OPERATOR MANUAL (CSOM) 
PURPOSE: The Computer System Operator Manual (CSOM) provides 
information 
for operating and performing diagnostics on a given 
computer and its peripheral equipment. 
A CSOM is developed for new or special-purpose 
computers for which commercial or other manuals are not 
readily available. 
CONTENTS: This document contains operator instructions. 


Paragraphs that have been tailored out of the DID shall 
result in the corresponding paragraph number and title 
in the document, followed by "This paragraph has been 
tailored. out..." 


Document Structure: 


ASA Scope 
iol Laentitication 
1.2 Computer system overview 
1.3 Document overview 


ae Referenced documents 
35 Computer system operation 
3.1 Computer system preparation and shutdown 
spe ap be Power on and off 
el alyae inueoTat Lon 
SP De) Shutdown 
3.2 Operating procedures 
SZ Input and output procedures 
Seige Monitoring procedures 
ay eee Recovery procedures 
Be oe Off-line routine procedures 
Lia Aes) Other procedures 


4. Diagnostic features 
4.1 Diagnostic features summary 
4.2 Diagnostic procedures 
4.3 Diagnostic tools 

Dis Notes 

6. Appendixes 
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: Scope. This section shall be divided into the 
following paragraphs. . 


staal Identification. This paragraph shall ‘contain the 
identification number, title, and abbreviation, as 
applicable, of the computer system to which this CSOM 
applies. 


ek Computer system overview. This paragraph shall briefly 
State the purpose of the computer system to which this 
CSOM applies. 


ies Document overview. This paragraph shall summarize the 
purpose and contents of this manual. 


2. Referenced documents. This section shall list by 
document number and title all documents referenced in 
this manual. This section shall also identify the 
source for all documents not available through normal 
Government stocking activities. 


By Computer system operation. This section shall be 


divided into the following paragraphs. This section may 
reference commercially available documents for the 
information required. 


cae Computer system preparation and shutdown. This 
paragraph shall be divided into the following 
subparagraphs. 

Boa: Power on and off. This paragraph shall explain the 


step-by-step 
procedures required to power-on and power-off the 
computer system. 


Sele Initiation. This paragraph shall contain the 
initiation 
procedures necessary to operate the computer system, 
including, as applicable: 


a. The equipment setup and the procedures required 
EOL 
pre-operation 


lobe Procedures necessary to bootstrap the computer 
system and 
load software and data 


Gy The commands typically used during computer system 
initiation 
a. The procedures necessary to initialize files, 


variables, or 
other parameters 
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ete vans Shutdown. This paragraph shall contain the shutdown 
procedures 
necessary to save data files and other information and 
to terminate computer system operation. 


aca Operating procedures. This paragraph shall be divided 
into the following subparagraphs. If more than one mode 
of operation is available, instructions for each mode 
shall be provided. 


CE Input and output procedures. This paragraph shall 


describe the 
input and output media (e.g., magnetic disk, tape) 
relevant to the computer system, state the procedures 
to read and write on these media, briefly describe the 
operating system control language, and list procedures 
for interactive messages and replies (e.g, terminals to 
use, passwords, keys). 


Be 2s2 Monitoring procedures. This paragraph shall contain 

the 
procedures to be followed for monitoring the computer 
system in operation. It shall describe applicable 
trouble and malfunction indications, evaluation 
techniques for fault isolation, conditions requiring 
computer system shutdown, and procedures for on-ine 
intervention, abort, and user communications. 


S23 Recovery procedures. This paragraph shall describe the 

automatic 
and manual procedures to be followed for each trouble 
occurrence (e.g., give detailed instructions to obtain 
computer system dumps). It shall describe the steps to 
be taken by the operator to restart computer system 
operation after an abort or interruption of operation. 
Procedures for recording information concerning a 
malfunction shall also be included. 


a. 2.4 Off-ine routine procedures. This paragraph shall 


contain the 
procedures required to operate all relevant off-ine 
equipment/ outines of the computer system. 


PAPAS Other procedures. This paragraph shall contain any 
additional 
procedures to be followed by the operator (e.g., 
computer system alarms, computer system security or 
privacy considerations, switch over to a redundant 
computer system or other measures to ensure continuity 
of operations in the event of emergencies) . 


4. Diagnostic features. This section shall be divided 
into the following paragraphs to describe the 
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diagnostic features available to the computer operator. 
This section may reference commercially available 
documents for the information required. 


Diagnostic features summary. This paragraph shall 


summarize the diagnostic features of the computer 
system, including error message syntax and hierarchy 
for fault isolation. This paragraph shall describe the 
purpose of each diagnostic feature. 


Diagnostic procedures. This paragraph shall be divided 
into subparagraphs as needed to describe the diagnostic 
procedures to be followed for the computer system, 

ine luding : 


a. Hardware, software, or firmware necessary for 
executing each 

procedure 
De Step-by-step instructions for executing each 
procedure ; 
on Diagnostic messages and the corresponding required 
action 


Diagnostic tools. This paragraph shall be divided into 
Subparagraphs as needed to describe the diagnostics 
tools available for the computer system. These tools 
may be hardware, software, or firmware. This paragraph 
shall identify each tool by name and number and shall 
describe the tool and its application. 


Notes. This section shall contain any general 
information that aids in understanding this document 
(e.g., background information, glossary). This section 
shall include an alphabetical listing of all acronyms, 
abbreviations, and their meanings as used in this 
document and a list of terms and definitions needed to 
understand this document. 


Appendixes. Appendixes may be used to provide 
information published separately for convenience in 
document maintenance (e.g., charts, classified data). 
As applicable, each appendix shall be referenced in the 
main body of the document where the data would normally 
have been provided. 
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DOCUMENT : 


PURPOSE: 


CONTENT : 


BLM 80013B 
VERSION DESCRIPTION DOCUMENT (VDD) 


The Version Description Document (VDD) identifies and describes a 
software version containing one or more Computer Software 
Configuration Items (CSCIs). It is used to release, track, and 
control software versions. 


The term "version" may be applied to the initial release of the 
software, to a subsequent release of that software, or to one of 
multiple forms of the software released at approximately the same 
time (for example, to different sites). 


This Data Item Description (DID) contains the format and content 
preparation instructions. 


For small development projects this DID can be incorporated into 
an alternative document. 


Title page or identifier. When data are delivered in the form of 
a traditional document, the document shall include a title page 
containing, as applicable: document number; volume number; 
version/revision indicator; security markings or other 
restrictions on the handling of the document; date; document 
title; name, abbreviation, and any other identifier for the 
System, subsystem or item to which the document applies; contract 
number; CDRL item number; organization for which the document has 
been prepared; name and address of preparing organization. For 
data delivered in an alternative form, this information shall be 
included on external and internal labels or by equivalent 
identification methods. 


Paragraphs that have been tailored out of the DID shall result in 
the corresponding paragraph number and title in the document, 
followed by "This paragraph has been tailored out." For data 
delivered in an alternative form, this representation need occur 
only in the table of contents or equivalent. 


DOCUMENT STRUCTURE: 


aby Scope 
ih Saks AWel=\ahwats deer Woukeyal 


1.2 System overview 

1.3 Document overview 
eae Referenced documents 
ae Version description 


3.1 Inventory of materials released 
Zz Inventory of CSCI contents 

.3 Changes installed 

-4 Adaptation data 

5 Interface compatibility 
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Bibliography of reference documents 
Operational effect of changes 
Installation instructions 

Possible problems and known errors 
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Notes 


Appendixes 
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Scope. This section shall be divided into the following 
paragraphs. . 


Identification. This paragraph shall contain a full 
identification of the system and the CSCIs to which this document 
applies, including, as applicable, identification number(s), 
title(s), abbreviation(s), version number(s), and release 
number(s). It shall also identify the intended recipients of the 
VDD to the. extent that this identification affects the contents 
of the software released (for example, source code may not be 
released to all recipients.) 


System overview. This paragraph shall briefly state the purpose 
of the system and the software to which this document applies. 
It shall describe the general nature of the System and software; 
summarize the history of system development, operation, and 
maintenance; identify the project sponsor, user, developer, and 
Support agencies; identify current and planned operating sites; 
and list other relevant documents. 


Document overview. This paragraph shall summarize the purpose 
and contents of this document. 


Referenced documents. This section shall list by document number 
and title all documents referenced in this document. This 
section shall also identify the source for all documents not 
available through normal Government stocking activities. 


Version description. This section shall be divided into the 
following paragraphs. 


inventory of materials released. This paragraph shall list: 


a. All physical media (e.g., listings, tapes, disks) and 
associated documentation that make up the software version 


De All operation and support documents that are not a part of 
the delivered package, but that are required to operate, 
load, or regenerate the software version 


ce Security and privacy considerations for these items, 
including classification levels 


robs Safeguards in handling the materials, such as concerns for 
static and magnetic fields 


e. Duplication instructions and restrictions 


inventory of CSCI contents. This paragraph shall identify all 
software in the version and any applicable security and privacy 


considerations. If source code is included, it shall be 
identified in the same sequence as is used to organize the source 
code listings for delivery. 
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Changes installed. This paragraph shall contain a list of all 
changes incorporated into the software since the previous 
version, with cross references to affected specifications. If 
change classes have been used, such as the Class I/Class II 
changes in [77-SDS-000102, Software Development Standards], the 
changes shall be separated into these classes. This paragraph 
shall also identify, as applicable, the problem reports, 
Engineering Change Proposals (ECPs), and Specification Change 
Notices(s).(SCNs) associated with each change. Note: This 
paragraph does not apply to the initial software version. 


Adaptation Gata. This paragraph shall identify or reference all 
unique-to-site data contained in the software version. For 
software versions after the first, this paragraph shall describe 
changes made to the adaptation data. 


Interface compatibility. This paragraph shall indicate other 
systems and configuration items, including version numbers, with 
which this software version interfaces and any impacts on those 
interfaces due to the changes incorporated in this version. 


Note: This paragraph does not apply to the initial BOSE ate 
version. 


Bibliography of reference documents. For the initial software 


version , this paragraph shall list all documents pertinent to 
the CSCI(s) in the version. For subsequent versions, this 
paragraph shall identify changes to the listed documents. 


Operational effect of changes. This paragraph shall contain a 


subparagraph describing the operational effect of each change 
listed in 3.3 above. This description shall include problems 
corrected, new or changed capabilities, and other operational 
effects. 


Installation instructions. This paragraph shall provide, as 
applicable: 


a. The instructions (either directly or by reference) for 
installing the software version. (Items shall be reference 
only if it is certain that recipients have or can get them) 


be Identification of other changes that have to be installed 
for this version to be used 


oy Any security, privacy, or safety precautions relevant to the 
installation 
ou Test procedures for determining whether the version has been 


installed properly 


e. Instructions for reaching a "help desk" if there are 
problems with the installation 
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Possible problems and known errors. This paragraph shall 
identify any possible problems or known errors with the software 
version, any steps being taken to resolve the problems or errors, 
and instructions (either directly or by reference) for 
recognizing, avoiding, correcting, or otherwise handling each 
one. The information presented shall be appropriate to the 
intended recipient of the VDD (for example, a user agency may 
need advice on avoiding errors, a support agency on correcting 
them) . 


Notes. This section shall contain any general information that 
aids in understanding this document (e.g., background 
information, glossary). This section shall include an 
alphabetical listing of all acronyms, abbreviations, and their 
meanings as used in this document and a list of any terms and 
definitions needed to understand this document. 


Appendixes. Appendixes may be used to provide information 
published separately for convenience in document maintenance 
(e.g., charts, classified data). As applicable, each appendix 
shall be referenced in the main body of the document where the 
data would normally have been provided. 


rt 


= tie TGQ: Sia 

z aN Ytte GWOkS 
af i ; Bi S6V206S° 

pits rier Vo 

cai pwerterl tO. 

: i MIs OA : 
1 ue 
j f ; ye 
> 
, 


ASRRS oat Sag spice Cle ey PASI 
“6 ameidorg oidlanog ar i de) 
of @inss pribed age7e YRE a0 7 


palisexryoq ,oaliiove Ngee 


fiL® HS areas Col. ert tat eft 
it) CiQV add 30 .2ABigtes baba Jak 


emuookb oids pobbassteteatbay af: apbam 


ey a“ Hf. ; 


‘+eetth saediske) enokgowtseke “bes. 


pio7te palbioeva no 4 sivine habit 
- ania 


=) 6% * 4 «a & ry | 7 { t ei 5 GB Law| wy « BeJoM 


e bri) (viseedip ol Jeeg63eee 
6 Li6 Fo poatsjert is5ka diacpe Se 
. : ims of Debt epolceg 


aheay etorss Jae 


| : tha@eqge arte 
kav 5} yistsvege Derek lame 
Seialearic (|asgze re »- P89 

' bs! iS + od LE ee | 

an ; Sisow Boao 


DOCUMENT: BLM C-80013B 


CONSOLIDATED SOFTWARE SUPPORT 
DOCUMENT (C-SSD) 


Alternate For: 


» Firmware Support Manual - BLM 80022A 
; Software Product Specifications - BLM 80029A 
Version Description Document - BLM 80013A 
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PURPOSE: 


CONTENTS : 


BUOMSC-8s00135 
CONSOLIDATED SOFTWARE SUPPORT DOCUMENT (C-SSD) 


The Consolidated Software Support Document (C-SSD) is a single 
document encompassing the version description, product 
specification, and support manuals for one or more CSCIs. 


This document contains, in summary form, the contents of the 
Version Description Document(s) (VDDs), Software Product 
Specification(s) (SPSs), Computer Instruction Set Architecture 
Manual(s) (CISAMs), and Firmware Support Manual(s) (FSMs) fora 
project. 


Paragraphs that have been tailored out of the DID shall result in 
the corresponding paragraph number and title in the document, 
followed by "This paragraph has been tailored out." 


DOCUMENT STRUCTURE: 


ibe Scope 
1.1 Identification 
1.2 System overview 
1.3 Document overview 


A Referenced documents 
ae Version description 
3.1 Inventory of materials released 
Baer inventory, of CSCi contents 
3.3 Changes installed 
3.4 Adaptation data. 
3.5 Bibliography of reference documents 
3.6 Operational effect of changes 
3.7 Installation instructions 
3.8 Possible problems and known errors 
4 Software product specification 
4.1 Software design 
4.2 Source code listings 
4.3 Compilation/build procedures 
4.4 Measured resource utilization 
4.5 Modification procedures 
ahs Computer instruction set architecture manual 
5.x (Computer system name and identifier) 


5.x.1 Programming environment 
5.x.2 Programming information 
6. Firmware Support Manual 
6.1 Firmware device information 
6.2 Programming equipment and procedures 
6.3 Vendor information 
d's Notes 
S Appendixes 
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Scope. This section shall be divided into the following 
paragraphs. 


Identification. This paragraph shall contain a full identific- 
ation of the system and the CSCIs to which this document applies, 
including, as applicable, identification number(s), title(s), 
abbreviation(s), version number(s), and release number(s). 


System overview. This paragraph shall briefly state the purpose 
of the system and the software to which this document applies. 
It shall describe the general nature of the system and software; 
summarize the history of system development, operation, and 
Maintenance; identify the project sponsor, user, developer, and 
Support agencies; identify current and planned operating sites; 
and list other relevant documents. 


Document overview. This paragraph shall summarize the purpose 
and contents of this document. 


Referenced documents. This section shall list by document number 
and title all documents referenced in this document. This 
section shall also identify the source for all documents not 
available through normal Government stocking activities. 


Version description. This section shall be divided into the 
following paragraphs to identify and describe a software version 
containing one or more Computer Software Configuration Items 
(CSCIs) . 


Inventory of materials released. This paragraph shall list: 


a. All physical media and documentation that make up the new 
version 
bs All operation/support documents that are not a part of the 


delivered package, but are required to operate, load, or 
regenerate the software version 

Security and privacy considerations for these items 
Required safeguards in handling the materials 
Duplication instructions and restrictions 


0 aA 


Inventory of CSCI contents. This paragraph shall identify all 
software that is part of the software version. If source code is 
included, it shall be identified in the same sequence as is used 
to organize the source code listings for delivery. Security and 
privacy considerations shall be included, as applicable, 
including the classification levels of the version contents. 


Changes installed. This paragraph shall contain a list of all 
changes incorporated into the software version since the 
previous version, with a cross reference to the affected 
system and software specifications. If change 
classifications have been used, such as the Class I/Class II 
changes described in the Configuration Management Plan, the 
changes shall be separated into these classifications. 
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This paragraph shall also identify, as applicable, the 
problem reports, Engineering Change Proposals (ECPs), and 
Specification Change Notices(s) (SCNs) associated with each 
change. Note: This paragraph does not apply to the initial 
software version. 


Adaptation data. This paragraph shall identify or reference all 
unique-to-site data contained in the software version. For 
software versions after the first, this paragraph shall describe 
changes made to the adaptation data. 


Interface compatibility. This paragraph shall indicate other 
systems and configuration items, including version numbers, with 
which this software version interfaces and any impacts on those 
interfaces due to the changes incorporated in this version. 
Note: This paragraph does not apply to the initial software 
version. 


Bibliography of reference documents. For the initial software 
version, this paragraph shall list all documents pertinent to the 
CSCI(s) in the version. For subsequent versions, this paragraph 
shall identify changes to the listed documents. 


Operational effect of changes. This paragraph shall contain a 
sub-paragraph describing the operational effect of each 
change listed in 3.3 above. This description shall 
include problems corrected, new or changed 
Capabilities, and other operational effects. 


Installation instructions. This paragraph shall provide, as 
applicable: 


a. Instructions (either directly or by reference) for 
installing the software version 

Ds Identification of other changes that have to be installed 
for this version to be used 

Cz Any security, privacy, or safety precautions relevant to the 
installation 

d. Test procedures for determining whether the version has been 
installed properly 

e. A telephone number or access to a "help desk" to call ot 


there are problems 


Possible problems and known errors. This paragraph shall 
identify any possible problems or known errors with the software 
version, any steps being taken to resolve the problems or errors, 
and instructions (either directly or by reference) for 
recognizing, avoiding, correcting, or otherwise handling each 
one. 


Software product specification. This section shall be divided 
into the following paragraphs to provide source code listings, 
compilation/build procedures needed to convert the source code 
into executable code, and (by inclusion or reference) design 
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information needed to understand and ed een the source 
code as required. 


Software design. This paragraph shall contain, or reference an 
appendix or other deliverable document that contains information 
describing the design of one or more "as-built" (delivered) 
CSCI(s). The information shall be the same as that required ina 
Software Design Document (SDD), Interface Design Document (IDD), 
and Database Design Document (DBDD), as applicable. If these 
documents or their equivalents are to be delivered for the "as- 
built" CSCI, this paragraph shall reference them. If not, the 
information shall be provided in this document. Information 
provided in headers, comments, and code of the source code 
listings may be referenced and need not be repeated in this 
paragraphs) ifsthe SDD, IDD, or DBDD is included in an appendix, 
the paragraph numbers and page numbers need not be changed. 


Source code listings. This paragraph shall contain, or reference 
an appendix that contains, the source code listings for one or 
more CSCIs. This paragraph shall provide an index that cross- 
references each software unit to the location in the listings 
where the code corresponding to that unit can be found and any 
comments useful in accessing or interpreting the listings. 


Compilation/build procedures. This paragraph shall describe, or 
reference an appendix that describes, the compilation/build 
process used to create the executable software product from the 
source code. It shall specify the compiler(s)/assembler(s) used; 
other hardware and software needed; any See Caner aan 
conventions used; and procedures for compiling/assembling, 
linking, and building the CSCI and the software system/subsystem 
containing the CSCI, including variations for different sites, 
configurations, versions, etc. 


Measured resource utilization. This paragraph shall specify the 
measured resource utilization of the CSCI(s) at the time of 
delivery. 


Modification procedures. This paragraph shall describe 
procedures that must be followed to modify the CSCI(s). It shall 
include or reference information on the following, as applicable: 


a. Support facilities, equipment, and software, and procedures 
for their use 

Db: Databases/data banks used by the CSCI and procedures for 
using them 

he Design or coding conventions to be followed 

d. Compilation/build procedures if different from those above 

e. Integration and testing procedures to be followed 

t. Error conditions, and procedures for responding to them 


Computer instruction set architecture manual. This section shall 
be divided into the following paragraphs to provide 


information 
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needed by programmers to understand the instruction set 
architecture of one or more new or special-purpose computers for 
which commercial or other programmer reference manuals are not 
available. 


(Computer system name and identifier). This paragraph shall 


provide full identification of a computer system to be described. 


Programming.environment. This paragraph shall be divided into 
subparagraphs as needed to provide the following information. 


a. The components and configuration of the computer system 


D> Operating characteristics of the computer system, including, 
as applicable: 


1) Machine cycle time 

2) Word length 

3) Memory capacity and characteristics 

4) Instruction set characteristics 

5) Interrupt capabilities 

6) Modes of operation (e.g., batch, interactive, 
privileged, non-privileged) 

7) Operational registers 

8) Error indicators 

9) Input/output characteristics 


10) Special features 


oe Equipment and software needed to perform compilations and 
assemblies on the computer system; name and version number 
of the editor, linker, link-editor, compiler, assembler, 
cross-compilers/assemblers, and other utilities used, and 
reference to appropriate manuals describing their use; any 
special flags or instructions necessary for loading, 
executing, or recording the results of compilations and 
assemblies. 


Programming information. This paragraph shall be divided into 
subparagraphs as needed to provide the following information for 
the computer system: 


a. The computer’s instruction set architecture, including, as 
applicable: 
1) Data representation (e.g., byte, word, integer, 
floating-point) 
2) Instruction formats and addressing modes 
3) Special registers and words (e.g., stack pointer) 
4) Gontrol anstructionsa(etg:, «branch, jump; calls) 
5) Subroutines and procedures 
6) Interrupt processing 
7) Timers and clocks 
8) Memory protection features (e.g., read-only memory) 
9) Additional features 
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a Description of each instruction in the instruction set 
architecture, including as applicable: 


25) Use 
2) Syntax 
3) Condition codes set 
4) Execution time 
5) Machine-code format 
6) Mnemonic conventions 
7) Other characteristics 
Gx The input and output control programming of the computer 
system, including, as applicable, descriptions of: 
2) Initial loading and verification of computer memory 
2) Serial and parallel data channels 
3) Discrete inputs and outputs 
4) Interface components 
5) Device numbers, operational codes, memory locations for 


peripheral equipment 


di. Additional or special techniques (e.g., microprogram 
control) 

e. Examples that demonstrate the programming features described 
above 

ie Error detection and diagnostic features 


Firmware support manual. This section shall be divided into the 
following paragraphs to provide information needed to load 
software or data into the firmware components of a system. 


Firmware device information. This paragraph shall be divided 
into subparagraphs as needed to describe the firmware devices. 
Included shall be: 


ae A complete physical description of the firmware components, 
gnedudaing: 
1) Device name and manufacturer’s ID and number 
2) Memory size and configuration (e.g., 64Kx1, 8Kx8) 
3) Operating characteristics (e€.g., access time, power 
requirements, logic levels) 
4) Pin functional descriptions 
5) Logical interfaces (e.g., addressing scheme, chip 
selection, etc.) 
6) Internal and external ID scheme used with each device 
2) Timing diagrams 
b. Installation, replacement, and repair procedures for the 


firmware devices 


eke Security and privacy measures to be applied to the devices 
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ols Operational and environmental limits to which the devices 
may be subjected and still maintain satisfactory operation 


Programming equipment and procedures. This paragraph shall be 


divided into subparagraphs as needed to describe the 
equipment, software, and procedures to be used for 
programming and reprogramming all firmware components 
of the system. Included shall be: 


a. Description of the equipment to be used for programming and 
reprogramming each firmware device, including manufacturer, 
manufacturer’s designation, description, purpose, usage, and 
major capabilities 


eh Description of the software to be used for programming and 
reprogramming each firmware device, including vendor’s 
designation, version, description, purpose, usage, and major 


capabilities 

(or Procedures to be used for programming and reprogramming each 
firmware device, including device loading, verification, and 
test 


Vendor information. This section shall include information 
Supplied by the device vendor or reference the appropriate 
commercially available document(s). This section shall also 
include all commercially available information for support 
equipment and software or shall reference the commercially 
available document(s). 


Notes. This section shall contain any general information that 
aids in understanding this document (e.g., background inform- 
ation, glossary). This section shall include an alphabetical 
listing of all acronyms, abbreviations, and their meanings as 
used in this document and a list of any terms and definitions 
needed to understand this document. 


Appendixes. Appendixes may be used to provide information 
published separately for convenience in document maintenance 
(e.g., charts, classified data). As applicable, each appendix 
Shall be referenced in the main body of the document where the 
data would normally have been provided. 
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PURPOSE: 


CONTENT : 


BLM 80008B 


SYSTEM/SEGMENT SPECIFICATION (SSS) 


The System/Segment Specification (SSS) specifies the require- 
ments for a system or a segment of a system. 


The SSS is used as the basis for developing and testing the 
system or segment. Upon Bureau approval, the SSS becomes the 
Functional.Baseline for the system or segment. Throughout this 
DID, the term "system" may be interpreted to mean "Segment" as 
applicable. 


This Data Item Description (DID) contains the format and content 
preparation instructions. 


This DID is an alternative to the Consolidated Software 
Requirements Document and Consolidated Software Development 
Record. Only one of these three DIDS should be Saree toa 
given set of data. 


Paragraphs that are tailored out of the DID shall result in the 
corresponding paragraph number and title in the document, 
followed by "This paragraph has been tailored out." 


DOCUMENT STRUCTURE: 


ue Scope. 
tel Identification? 
1.2 System overview. 
1.3 Document overview. 


aus Applicable documents. 
2.1 Government documents. 
2.2 Non-Government documents. 


cite Requirements. 
aie DeLinition. 
a.2 Characteristics. 
ciel Performance characteristics. 
Ch PAs Ecos (System capability name and project 
unique identifier). 
BZee Database/data bank requirements. 
Set (Database/data bank name). 
Ch baa} External interface requirements. 
Oa 3 (Interface name). 
Sn .4 Physical characteristics. 
Sj eee System. quality factors. 
ci Pome eal Reliability. 
NPA Da be iP Maintainability. 
Le PA keae) Availability. 
Be. ee Additional quality factors. 
Br) Environmental requirements. 
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38266131 Environmental conditions. 

Bie. 6.2 Computer equipment environment. 
Cy Ee Ue Support software environment. 
a. 2e6n4 Communications environment. 


34227 Transportability. 
322.8 Flexibility and expansion. 
a.2e9 Portability. 
3.3 Design and construction. 
333 Materials. 
S33). 2 Electromagnetic radiation. 
Dee ore) Nameplates and product marking. 
8,324 Workmanship. 
ae.3,5 Interchangeability. 
Bone Safety. 
Sia Wa Human engineering. 
oe375 Nuclear control. 
BE3S59 System security and privacy. 
3% 5..L0 Government furnished property usage. 
Be Sees Computer resource reserve capacity. 
3.4 Documentation. 
B25. LOdLstics < 
3.6 Personnel and training. 
Sm6e1 Personnel. 
Se One Training. 
3.7 Characteristics of subordinate elements. 
Bogiex (Segment name and project unique identifier) 


3.8 Precedence. 

Quality assurance provisions. 

4.1 Qualification methods. 

4.2 Special tests and examinations. 
Preparation for delivery. 


Notes. 


Appendixes. 
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Scope. This section shall be divided into the following para- 
graphs. 


Identification. This paragraph shall contain a full 
identification of the system to which this document applies, 
including, as applicable, identification number(s), title(s), 
abbreviation(s), version number(s), and release number(s) . 


System overview. This paragraph shall briefly state the purpose 
of the system to which this document applies. It shall describe 
the general nature of the system; summarize the history of system 
development, operation, and maintenance; identify the project 
sponsor, user, developer, and support agencies; identify current 
and planned operating sites; and list other relevant documents. 


Document overview. This paragraph shall summarize the purpose 
and contents of this document. 


Applicable documents. This section shall be divided into the 
following paragraphs. 


Government documents. Government documents shall be listed by 
document number and title. 


Non-Government documents. Non-Government documents shall be 
listed by document number and title in the same order as under 
2. 


Requirements. This section shall be divided into the following 
paragraphs to specify the requirements for the system to which 
this specification applies. The degree of detail shall be guided 
by the following: include those system characteristics that are 
conditions for system acceptance; defer to design documents those 
characteristics that the customer is willing to leave up to the 
developer. In some cases, a given requirement may fit into more 
than one paragraph. Such requirements may be stated only once or 
included in all applicable paragraphs with cross-references among 
the occurrences. 


Definition. This paragraph shall provide a brief description of 
the system. This description shall address pertinent 
operational, interface, and logistical considerations and 
concepts. A system diagram shall be provided. If the system is 
required to operate in more than one state or mode having 
requirements distinct from other states or modes, this paragraph 
shall identify and define each state and mode. Examples of 
states and modes include: idle, ready, active, post-use analysis, 
training, degraded, emergency, backup, wartime, peacetime. The 
distinction between states and modes is arbitrary. A system may 
be described in terms of states only, modes only, states within 
modes, modes within states, or any other scheme that is useful. 
If the system operates without states or modes, this paragraph 
shall so state, without the need to create artificial 
distinctions. 
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Characteristics. This paragraph shall be divided into the 
following subparagraphs to describe the requirements for the 
system. Each requirement or group of requirements shall be 
annotated to indicate the states and modes in which it applies, 
either in the text, in an accompanying table, or by other means. 


Performance characteristics. This paragraph shall be divided 
into the following subparagraphs to specify the system’s 
capabilities. 


(System capability name and project unique identifier). This 


paragraph shall identify a capability of the system by name and 
project unique identifier, describe its purpose, and itemize the 
requirements for that capability. A "capability" is defined as a 
group of related requirements. The word "capability" may be 


replaced by "function," "Subject," "object," or other term useful 
for presenting the requirements. Each requirement shall be given 
a unique identifier. The requirements shall include applicable 


parameters, such as response times, sequencing, accuracy, 
Capacities (how much/how many), priorities, continuous operation 
requirements, and allowable deviations based on operating 
conditions, and shall express these parameters in measurable 
terms. The requirements shall also include required behavior 
under unexpected or "out of bounds" conditions. 


Database/data bank requirements. This paragraph shall specify 


any requirements imposed on databases/data banks that must be 
incorporated into the system. A data element dictionary may be 
referenced. (Note: If the existence, content, and format of 
system databases are left to the system designers, this shall be 
so stated in place of these requirements. ) 


(Database/data bank name). This paragraph shall identify a 
required database or data bank, state its purpose, and itemize 
the requirements imposed on the database or data bank, including 
the following as applicable: 


a. Required data elements 


Db. Required characteristics of the data elements, such as 
formats, lengths, units of measure, precision, range of 
values, special names, abbreviations, or codes 


roam Required relationships among data elements, such as ability 
to sort or access data in specified ways 


ae Required storage capacity for the data, including growth 
capability 


External interface requirements. This paragraph shall be divided 
into the following subparagraphs to specify any requirements for 


interfaces with other systems, equipment, support software and 
hardware, test software and hardware, external databases, and 
users. Detailed quantitative interface requirements may be 
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defined in separate specifications or interface control documents 
and referenced herein. All such referenced documents are 
considered part of this specification. 


(Interface name). This paragraph shall identify an external item 
with which this system is required to interface, including 
correct nomenclature, version, and documentation references, as 
applicable. This paragraph shall state the purpose of the 
interface, describe the relationship between the interface and 
the states and modes of the system and itemize the requirements 
imposed on the system as a result of the interface, including as 
applicable: 


a. Physical interface requirements (dimensions, tolerances, 
loads, etc.) 


be Communication/data transfer requirements (equipment, 
locations, speeds, media, communication protocols, 
languages, database management systems, procedures) 


CG. Nature of the inputs that must be accepted by the system 
from the interfacing item (as applicable: data element 
names, Synonymous names, definition, format, range or 
enumeration of values, units of measurement, codes, 
characteristics such as precision, accuracy, timing, and 


capacity. (A data element dictionary may be referenced ioe 
applicable.) 
a. Nature of the outputs that must be provided by the system to 


the interfacing item (as applicable: data element names, 
synonymous names, definition, format, range or enumeration 
of values, units of measurement, codes, characteristics such 
as precision, accuracy, timing, and capacity. (A data 
element dictionary may be referenced if applicable) 


e. Security or privacy requirements 


Physical characteristics. This paragraph shall specify any 
requirements for physical characteristics (e.g., weight limits, 
dimensional limits, color, protective coatings) of the system. 
Considerations for determining physical requirements include 
transportation and storage, security, privacy, durability 
(freedom from corrosion, abrasion, or other damage), safety, 
vulnerability. If there are no physical requirements (such as 
for a software-only system), this paragraph shall contain "Not 
Applicable." 


System quality factors. This paragraph shall be divided into the 
following subparagraphs to specify any requirements pertaining to 
system quality factors. 


Reliability. This paragraph shall specify any quantitative 
reliability requirements for the system and the conditions under 
which the reliability requirements are to be met. This paragraph 
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may include a reliability apportionment model to support 
apportionment of reliability values assigned to system 
capabilities for their share in achieving desired system 
reliability. It shall identify possible failures of the system, 
the consequences of such failures in terms of system performance, 
and alternative courses of action to be provided to satisfy 
system requirements. These may include backup (redundancy) 
provisions; fallback on other systems; retention/restoration 
priorities in the event of degraded operation; restart/recovery 
provisions; and other measures such as pre-establishment of 
alternate sites and capability for communications re-routing. 


Maintainability. This paragraph and shall specify any 
quantitative maintainability requirements for the system. The 
requirements shall apply to maintenance in the planned 
support/maintenance environment. Examples are: 


a. Mean and maximum down time, reaction time, turnaround 
time,mean and maximum times to repair, mean time between 
Maintenance actions 


De Maximum effort required to locate and fix an error 


C7 Maintenance man-hours per flying hour, maintenance man-hours 
per specific maintenance action, operational ready rate, 
maintenance hours per operating hour, frequency of 
preventative maintenance 


a: Number of people and skill levels, variety of support 
equipment 

e. Maintenance costs per operating hour, man-hours per 
overhaul 

Availability. This paragraph shall specify any requirements 


regarding the degree to which the system shall be in an operable 
and committable state when needed. 


Additional quality factors. This paragraph shall specify any 
other system quality requirements not defined in the above 
subparagraphs (e.g., integrity, efficiency, or correctness 
requirements of the system). 


Environmental requirements. This paragraph shall be divided into 
the following subparagraphs to specify any requirements 
concerning the environment within which the system is required to 


operate. 


Environmental conditions. This paragraph shall specify any 
environmental conditions that the system must with-stand during 
transportation, storage, and operation, such as: 


a. Natural environment (e.g., wind, rain, temperature, 
geographic location) 
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bb: Induced environment (e.g., motion, shock, noise, 
electromagnetic radiation) Cy Environments due to enemy 
action (e.g., over-pressure, explosions, radiation) 


Computer equipment environment. This paragraph shall specify any 
requirements regarding computer equipment that must be used by, 


or incorporated into, the system. The requirements shall 
include, as applicable, number of each type of equipment, type, 
size, capacity, and other required characteristics of processors, 
storage media, input/output devices, and other required 
equipment. 


Support software environment. This paragraph shall specify any 
requirements regarding Support software that must be used by, or 


incorporated into, the system. Examples include Ota Laty 
software, input and equipment simulators, test software, and 
manufacturing software. The correct nomenclature, level 
(version), and documentation references of each such software 
item shall be provided. In addition, the language, operating 
System, and any Database Management System that must be used 
shall be identified. 


Communications environment. This paragraph shall specify any 
requirements concerning the communications environment within 
which the system must operate. The requirements shall include 
the following, as applicable. Charts or diagrams may be used as 
needed. 


a. Network requirements: required numbers of computers and 
terminals; geographic locations; configuration and network 
topology; transmission technique; data transfer rates; 
gateways; required system use times; type and volume of data 
to be transmitted/received; time boundaries for 
transmission/reception/response; peak volumes of data; 
required communications hardware and software 


jaye Physical interface requirements: required line speed 
capability; electrical interface specifications; hardware 
requirements; transmission requirements 


“en Protocol requirements: required headers; footers; formats; 
priorities; communication conventions 


ae User interfaces: required interfaces between communication 
modules and user 


e. Diagnostics: required diagnostic features to be available to 
users, computer operations personnel, and field assistance 
personnel 


Transportability. This paragraph shall specify any special 
requirements for transportation and materials handling. [In 
addition, all system elements that will be unsuitable for normal 
transportation methods shall be identified. 
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Flexibility and expansion. This paragraph shall specify any 
anticipated areas of growth that require planning for system 


flexibility and expansion. In addition, this paragraph shall 
specify any system elements that require spare Capacity to 
Support flexibility and expansion. 


Portability. This paragraph shall specify any requirements for 
portability to permit employment, deployment, and logistic 
Support. Portability for hardware is the ease with which an item 
can be carried, usually by a person. Portability for software is 
the ease with which it can be rehosted on different computer 
equipment. 


Design and construction. This paragraph shall be divided into 
Subparagraphs that specify any minimum system design and 
construction standards that have general applicability to system 
equipment and are applicable to major classes of equipment (e.g., 
aerospace vehicle equipment and support equipment) or are 
applicable to particular design standards. To the maximum extent 
possible, these requirements shall be specified by incorporation 
of the established military standards and specifications. 
Requirements that add to, but do not conflict with, requirements 
specified herein may be included in individual configuration item 
Specifications. In addition, this paragraph shall specify 
criteria for the selection and imposition of Hederal, military, 
and contractor specifications and standards. 


Materials. This paragraph shall specify any requirements 
governing use of materials, parts, and processes in the design of 
System equipment. It shall include, as applicable: 


a Requirements to prevent unnecessary use of strategic or 
critical materials. (A strategic and critical materials 
list may be obtained from the contracting agency.) 


b. Requirements for the use of standard and commercial parts 
and parts for which qualified products lists have been 
established 


Cs Requirements for the control of toxic products or 
formulations to be used in the system or to be generated by 
the system 


Electromagnetic radiation. This paragraph shall specify any 
requirements pertaining to limits on the electromagnetic 


radiation that the system is permitted to generate. 


Nameplates and product marking. This paragraph shall specify any 


requirements for nameplates, part marking, serial and lot number 
marking, software media marking, and other identifying markings 
required for the system. Reference may be made to existing 
Standards on the content and application of markings. 


Workmanship. This paragraph shall specify any workmanship 
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requirements for equipment to be produced during system 
development and production techniques. 


Interchangeability. This paragraph shall specify any 
requirements for system equipment to be interchangeable and 
replaceable. Entries in this paragraph are for the purpose of 
establishing a condition for design and are not to define the 
conditions of interchangeability required by the assignment of a 
part number. 


Safety. This paragraph shall specify any safety requirements for 
the system, with respect to equipment characteristics, methods of 
operation, and environmental influences. This paragraph shall 
specify any safety requirements for preventing personnel injury 
and equipment degradation without degrading operational 
capability (e.g., restricting the use of dangerous materials 
where possible, classifying explosives for purposes of shipping, 
handling and storing, abort/escape provisions from enclosures, 
gas detection and warning devices, grounding of electrical 
system, cleanliness and decontamination, explosion proofing). 


Human engineering. This paragraph shall specify any human 
engineering requirements for the system. This paragraph shall 
reference applicable documents and specify any special or unique 
requirements (e.g., constraints on allocation of capabilities to 
personnel and communications, and personnel/ equipment 
interactions). This paragraph shall identify specific areas, 
stations, or equipment that would require concentrated human 
engineering attention due to the sensitivity of the operation or 
criticality of the task; i.e., those areas where the effects of 
human error would be particularly serious. 


System security and privacy. This paragraph shall specify any 
requirements for system security and privacy. These requirements 


shall include the following, as applicable (to control 
dissemination of sensitive information, all or portions of this 
paragraph may be maintained and distributed separately from the 
remainder of the document) : 


a. Background information on the sensitivity and classification 
of the application 


by A description of each anticipated control point (points 
where there is a vulnerability requiring safeguards), 
including, as applicable, input control points (such as 
points Of Origin of data, data entry points, 
storage/disposal points for source data after entry, error 
detection/correction points); process control points (such 
as points providing notification of success/failure of 
processing requests, and points where data will pass to or 
from other systems); and output control points (such as 
devices that will receive output and steps involved in 
distribution of outputs) 
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oe A description of the anticipated vulnerabilities at each 
control point (that is, each design, implementation, or 
operational condition inherent in the system that lends 
itself to error, loss, or compromise of information or 
denial of service) 


ae Requirements for safeguards at each control point to reduce 


the vulnerabilities, including as applicable: 


1) Administrative (procedural) safeguards on personnel 
clearances/authorizations, data collection/preparation, 
time or other constraints on the operational 
environment, data distribution, access permissions 


2a Physical safeguards (doors, locks, etc.) for dedicated 
equipment and for storage and protection of materials 


3) Technical (automated) safeguards (passwords, read/write 
keys, etc) for controlling user access, detecting 
abnormal patterns of user, data validation/encryption, 
automated labeling/display of security identification 


e. Requirements for system monitoring and auditing features, 
including as applicable: 


1) Requirements for journalizing (recording selected 
events as they occur), including triggering criteria 
(conditions that trigger an entry in the journal), 
identifying information (date, time,...) to be recorded 
for each entry, and application data to be recorded for 
each entry 


2) Requirements for an audit trail, such as total 
transaction counts processed by location, time, and 
type 


Government furnished property usage. This paragraph shall 
specify any Government Furnished Equipment (GFE) to be 


incorporated into the system design. In addition, this paragraph 
shall specify any Government Furnished Information (GFI) and 
Government Furnished Software (GFS) to be incorporated into the 
system. This list shall identify the Government furnished 
property by reference to its nomenclature, specification number, 
and/or part number. If the list is extensive, it may be included 
as an appendix to this specification and referenced in this 
paragraph. 


Computer resource reserve capacity. This paragraph shall specify 


any required computer resource reserve capacity (e.g. memory, 
eiming, etc. )-. 


Documentation. This paragraph shall specify any requirements for 
system documentation such as specifications, drawings, technical 
manuals, test plans and procedures, and installation instruction 
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data. 


Logistics. This paragraph specify any logistic considerations 
and conditions that apply to the operational requirements. These 
considerations and conditions may include: 


Maintenance 

Transportation modes 

Supply system requirements 
Impact on existing facilities 
Impact on existing equipment 


0aanoy 


Personnel and training. This paragraph shall be divided into the 
following subparagraphs to specify any requirements for personnel 
and training. 


Personnel. This paragraph shall specify any personnel require - 
ments that must be integrated into system design. These require- 
ments shall be stated in terms of numbers plus tolerance and 
Shall be the basis for contractor design and development 
decisions. Requirements stated in this paragraph shall be the 
basis for determination of system personnel training, training 
equipment, and training facility requirements. Personnel 
requirements shall include: 


a. Numbers and skills of support personnel for each operational 
deployment mode and the intended duty cycle, both normal and 
emergency 

Db; Skills and numbers of personnel that shall be allocated to 


the operation, maintenance, and control of the system 


Training. This paragraph shall specify any training require- 
ments, including as applicable: 


a. Contractor and Government responsibility for training: ee This 
paragraph shall also specify the concept of how training 
shall be accomplished (e.g., school, contractor training) 


is Equipment that will be required for training purposes 
ex Training devices to be developed, characteristics of the 


training devices, and training and skills to be developed 
through the use of training devices 


(aly Training time and locations available for a training program 
e. Source material and training aids to support the specified 
training 


Characteristics of subordinate elements. This paragraph shall be 
divided into subparagraphs to identify and describe each segment 
of the system. This paragraph shall describe the relationships 
among the segments. 
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(Segment name and project unique identifier). This paragraph 


Shall provide the following information for the segment : 


a. State the purpose of the segment 
bi Provide a brief description of the segment 
Gs Identify the system capabilities the segment is to perform 


Precedence. This paragraph shall specify any order of precedence 
or assigned weights indicating the relative importance of the 
requirements. 


Quality assurance provisions. This section shall be divided into 


the following paragraphs to specify the qualification require- 
ments for the system. 


Qualification methods. This paragraph shall define a set of 
qualification methods and specify the method(s) to be used to 


ensure that each requirement in sections 3 and 5 has been met. A 
table may be used to present this information. The methods shall 
state, as applicable, conditions of testing, time (program phase) 
of testing, period of testing, items to be to be tested, and any 

other pertinent information. Qualification methods may include 


a. Demonstration. The operation of the SVSCEM 7 Olea Dare. of 
the system, that relies on observable functional operation 
not requiring the use of instrumentation or special test 
equipment. 


b. Test. The operation of the system, or a part of the system, 
using instrumentation or other special test equipment to 
collect data for later analysis. 


cy Analysis. The processing of accumulated data obtained from 
other qualification methods. Examples are reduction, 
interpolation, or extrapolation of test results. d. 
Inspection. The visual examination of system components, 
documentation, etc. 


Special tests and examinations. This paragraph shall specify any 


Special tests and examinations required for sampling, lot 
formation, qualification evaluation, and any other tests or 
examinations as necessary. Included, as applicable, shall be use 
of standard samples, preproduction or periodic production 
samples, pilot models, or pilot lots. Each test and examination 
Shall be described in a separate subparagraph. 


Preparation for delivery. This section shall specify 


requirements for the preparation of the system and all its 
components for delivery, including packaging and handling. This 
section shall include requirements to document any non-standard 
practices in appropriate system end item specifications. This 
section may impose requirements to comply with standard practice 
by referencing appropriate military specifications and standards 
to be used as the basis for preparing Section 5 of each 
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specification for system end items. 


Notes. This section shall contain any general information that 
aids in understanding this document (e.g., background 
information, glossary, rationale). This section shall contain an 
alphabetical listing of all acronyms, abbreviations, and their 
meanings as used in this document and a list of any terms and 
definitions needed to understand this document. 


Appendixes. Appendixes may be used to provide information 
published separately for convenience in document maintenance 
(e.g., charts, classified data). As applicable, each appendix 
shall be referenced in the main body of the document where the 
data would normally have been provided. 
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